Thinking about kqueue's and pthread_cond_wait

[Randall Stewart]

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


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

Far better to have a unified approach IMO.

R

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)