Thinking about kqueue's and pthread_cond_wait

[John Baldwin]

On Wednesday 10 February 2010 7:10:53 pm Daniel Eischen wrote:
> On Feb 10, 2010, at 3:06 PM, Alfred Perlstein <alfred at freebsd.org>  
> wrote:
> 
> > * Daniel Eischen <deischen at freebsd.org> [100210 12:01] wrote:
> >>
> >>
> >> 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.
> 
> Don't misunderstand me, I just don't think running around the tree and  
> adapting all the userland leaves to kqueue-isize them is the right  
> approach.  IMHO, it's better to extend the kqueue/kevent mechanism to  
> allow a generic object to be added to the event list and the kqueue to  
> be signaled from userland.  All the pthread and semaphore functions  
> are userland operations that also rely on userland structures anyway.

kqueue/kevent already support that via EVFILT_USER, and Apple's GCD depends on 
this extensively.  However, my point from my earlier post still stands and I 
think it is the right way to implement something like NT's 
WaitForMultipleObjects().

-- 
John Baldwin