Thinking about kqueue's and pthread_cond_wait

[Alfred Perlstein]

* 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 Perlstein
.- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250
.- FreeBSD committer