Thinking about kqueue's and pthread_cond_wait

[Randall Stewart]

On Feb 10, 2010, at 12:06 PM, Alfred Perlstein wrote:

> * Daniel Eischen <deischen at freebsd.org> [100210 12:01] wrote:
>> 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...
>
> Well then you "win".  I have no desire to engage in such discussion.
>
> I do hope that when you see this facility leveraged elsewhere for
> an application that you reflect on this conversation and think back
> on it the next time an opportunity presents itself to lead in
> functionality.
>


Alfred:

I have to say lead would only be in the *nix domain.. the windows  
world (dare I say that)
has had the ability to mix things like condition variables and fd's  
for ages.. or at
least so I have been told (I have never coded in windows)...

But it would be nice to have a similar ability in FreeBSD.. but with  
DE so against it
I will just find another way ..

I guess what will happen is I will end up creating my own condition  
variable. I have
never been a fan of the mutex tied to it... so I may not build that  
unless folks
ask for it ;-) (I usually tend to be receptive to new features)....

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