Thinking about kqueue's and pthread_cond_wait

[Daniel Eischen]

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.

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).

-- 
DE