Thinking about kqueue's and pthread_cond_wait

[John Baldwin]

On Thursday 11 February 2010 11:49:03 am Daniel Eischen wrote:
> On Thu, 11 Feb 2010, John Baldwin wrote:
> 
> > 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().
> 
> I guess that didn't exist in my 9.0-current that I looked at, so
> I replied privately with something very similar ;-)  With this
> one could wrap pthread objects, semaphores, etc.  The wrapper
> functions would have to additionally call kevent() to trigger
> the event if the object was being waited on in a kqueue, as in:
> 
>  	typedef struct {
> #define MY_MTX_IN_KQUEUE	0x0001
>  		int flags;
>  		pthread_mutex_t mutex;
>  	} my_pthread_mutex_t;
> 
>  	my_pthread_mutex_unlock(my_pthread_mutex_t *m)
>  	{
>  		if (m->flags & MY_MTX_IN_KQUEUE) != 0) {
>  			/* Trigger the event. */
>  			kevent(...);
>  		}
>  		ret = pthread_mutex_unlock(m->mutex);
>  	}

I thought about doing something like this, but I think it is both kludgey and 
racy.  It also doesn't fit in nearly as nicely as in Windows where the 
standard system objects can be used with WaitForMultipleObjects().

-- 
John Baldwin