From owner-freebsd-threads@FreeBSD.ORG  Wed Feb 10 18:57:47 2010
Return-Path: <owner-freebsd-threads@FreeBSD.ORG>
Delivered-To: threads@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 4D0A11065679
	for <threads@freebsd.org>; Wed, 10 Feb 2010 18:57:47 +0000 (UTC)
	(envelope-from bright@elvis.mu.org)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.freebsd.org (Postfix) with ESMTP id 38C1C8FC19
	for <threads@freebsd.org>; Wed, 10 Feb 2010 18:57:47 +0000 (UTC)
Received: by elvis.mu.org (Postfix, from userid 1192)
	id EFB701A3E8D; Wed, 10 Feb 2010 10:57:46 -0800 (PST)
Date: Wed, 10 Feb 2010 10:57:46 -0800
From: Alfred Perlstein <alfred@freebsd.org>
To: Daniel Eischen <deischen@freebsd.org>
Message-ID: <20100210185746.GC71374@elvis.mu.org>
References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net>
	<Pine.GSO.4.64.1002101202060.13656@sea.ntplx.net>
	<3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net>
	<Pine.GSO.4.64.1002101232240.13876@sea.ntplx.net>
	<07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net>
	<Pine.GSO.4.64.1002101331240.14115@sea.ntplx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.64.1002101331240.14115@sea.ntplx.net>
User-Agent: Mutt/1.4.2.3i
Cc: threads@freebsd.org
Subject: Re: Thinking about kqueue's and pthread_cond_wait
X-BeenThere: freebsd-threads@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Threading on FreeBSD <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>, 
	<mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2010 18:57:47 -0000

* Daniel Eischen <deischen@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.

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