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 11:06] wrote:
>> 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.
>
> Again, this is not convenient.  It is more complex and error prone
> for users.

I strongly disagree.  Using mutexes and condition variables in the
proper way is not as easy as it sounds, let alone trying to mix
them as userland thingies into kqueue.

I will strongly oppose this...

-- 
DE