Thinking about kqueue's and pthread_cond_wait

[Daniel Eischen]

On Wed, 10 Feb 2010, Alfred Perlstein wrote:

> * Daniel Eischen <deischen at freebsd.org> [100210 10:50] wrote:
>> On Wed, 10 Feb 2010, Randall Stewart wrote:
>>
>>>
>>>
>>> while (notdone) {
>>>   nev = kevent(kq, , ev);
>>>   if (ev.fitler == EVFILTER_READ) {
>>>        handle_the_read_thingy(ev);
>>>   } else if (ev.filter == EVFILTER_COND) {
>>>        lock_mutex(if needed)
>>>        handle_condition_event();
>>>   }
>>> }
>>>
>>>
>>> One of the things I will note about a condition variable is that the
>>> downside is
>>> you ALWAYS have to have a mutex.. and not always do you need one... I have
>>> found
>>> multiple times in user apps where i am creating a mutex only for the
>>> benefit of
>>> the pthread_cond() api... sometimes just being woken up is enough ;-)
>>
>> [ I didn't see that you were waiting on multiple CVs... ]
>>
>> I don't understand why you need to wait on multiple
>> condition variables.  Either way, you have to maintain
>> a queue of them along with their associated mutexes and
>> then take some action unique to each one of them.  What
>> is the difference between that and maintaining a queue of
>> some other thingies that maintain similar state data?
>
> Developer convenience.
>
> If we offer a stable API and way of doing it right, then we offer
> a solid base for programs.  By making users roll their own we have
> them duplicate code and introduce errors, in fact the idea of how
> to get this working (using a pipe(2) loop back) is so esoteric to
> likely block a significant portion of users from solving this problem
> at all.

See the proposed solution hacking the pthread API and think twice
about that.

If you need a generic way of waiting and waking threads in kevent,
then extend the kqueue/kevent interface to allow it.  Add a userland
struct kq_wait object along with EVFILT_KQ_WAIT, and a syscall to
send wake up that event.

-- 
DE