Thinking about kqueue's and pthread_cond_wait

[Daniel Eischen]

On Wed, 10 Feb 2010, Randall Stewart wrote:

>
> On Feb 10, 2010, at 8:59 AM, Daniel Eischen wrote:
>
>> On Wed, 10 Feb 2010, Randall Stewart wrote:
>> 
>>> Alfred:
>>> 
>>> Basically I would like to have a dispatch/reactor loop that can
>>> wait on multiple events. Including a condition variable that might
>>> be in shared memory or for that matter some other thread awakening
>>> it to do something without having to create a pipe and write/read
>>> a byte.
>>> 
>>> A peer process could also "wake" the condition variable and this
>>> would then show up as an event in my dispatch loop, assuming the cond
>>> variable and mutex are in shared memory that is... For example a
>>> peer could plop some data in shared memory (via a shm queue or
>>> some such other construct) and then do a cond_wake() and ta-da
>>> coolness ;-)
>> 
>> Is it really that much different than creating a pipe and
>> adding it to the kevent list?  It seems pretty straight forward
>> to use a pipe rather than munge condition variables and mutexes
>> into kqueue.  Plus, we don't even support (yet) mutexes and
>> condition variables in shared memory, and if we did, this
>> solution wouldn't be too portable across different FreeBSD
>> releases.
>> 
>
>
> Hmm I thought someone said in 9 we are supporting shared memory
> pthreads... which I was hopeful for.. since that would avoid
> internal hacks..

So far only semaphores, but I believe David is working on
mutexes and condition variables.  But either way, that would
only be a solution for 9.

>> Whether you are using pthread_cond_signal() or write()'ing
>> a byte to the special pipe, you are still calling in to the
>> kernel to wake another thread stuck in kevent().  You could
>> also send a signal to the thread stuck in kevent() if you
>> wanted to wake it up (EVFILT_SIGNAL).
>
> But these are different things..

So are mutexes.  But they can achieve what you want to achieve.
All you want to do is wakeup a thread stuck in kevent().

Munging the pthread_ API is not a unified approach, IMHO.

-- 
DE