From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 20:06:31 2010 Return-Path: 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 834DE1065692; Wed, 10 Feb 2010 20:06:31 +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 6C5D68FC17; Wed, 10 Feb 2010 20:06:31 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 21D251A3E92; Wed, 10 Feb 2010 12:06:31 -0800 (PST) Date: Wed, 10 Feb 2010 12:06:31 -0800 From: Alfred Perlstein To: Daniel Eischen Message-ID: <20100210200631.GE71374@elvis.mu.org> References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> <20100210185746.GC71374@elvis.mu.org> <20100210191709.GD71374@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:06:31 -0000 * Daniel Eischen [100210 12:01] wrote: > On Wed, 10 Feb 2010, Alfred Perlstein wrote: > > >* Daniel Eischen [100210 11:06] wrote: > >>On Wed, 10 Feb 2010, Alfred Perlstein wrote: > >> > >>>* Daniel Eischen [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