Re: [ECOS] waking a thread that's in select()?

[Grant Edwards <grante at visi dot com>]

> > There is a function to break select out. Have a look at the end of
> > packanges/net/tcpip/current/src/lib/select.c.
> 
> In _cyg_select(), the call to cyg_flag_wait() looks like:
> 
>   flag = cyg_flag_wait(&select_flag,wait_flag,CYG_FLAG_WAITMODE_OR|CYG_FLAG_WAITMODE_CLR);

I'm still confused about what happens if there are multiple
theads waiting on select_flag.  According to the ecos reference
manual (and my perusal of flag.cxx): the WAITMODE_CLR means
that one thread will be woken, but the comments in select.c
imply that "any current selects" (plural) will be aborted:

// This function can be called by the user to forceably abort any
// current selects.
[...]
   // Signal any threads doing a 'select()' that I/O may be possible

[more source code browsing]

I'd been assuming that select()ing tasks were normally woken up
by selwakeup() in lib/select.c, but that could work right since
only the first task in the queue gets woken by a call to
cyg_flag_setbits().

Then I found the _other_ selwakeup() function in
sys/kern/sys_generic.c.  This version of selwakeup doesn't use
select_flag at all (obviously, since it's static), and appears
to wake up specific threads based on the "selinfo" struct it is
passed.

This means that under normal conditions (where nobody calls
cyg_select_abort()), setting bits in select_flag is not
actually used to wake up tasks.

So: why is flag_wait called with WAITMODE_CLR?  It looks to me
like cyg_select_abort() would come closer to working right w/o
the WAITMODE_CLR -- though there is still the problem with
threads that are in select() but not waiting on select_flag.

I should check CVS code, since I've been looking at 1.3.1....

-- 
Grant Edwards
grante@visi.com