Thinking about kqueue's and pthread_cond_wait

[Alfred Perlstein]

* 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 will review the _additions_ to the pthreads API to see if they
cause any performance issues for the "non-use" case.

-- 
- Alfred Perlstein
.- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250
.- FreeBSD committer