From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 20:01:55 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 B1930106566C; Wed, 10 Feb 2010 20:01:55 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 50E208FC13; Wed, 10 Feb 2010 20:01:54 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o1AK1rvk018657; Wed, 10 Feb 2010 15:01:53 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Wed, 10 Feb 2010 15:01:53 -0500 (EST) Date: Wed, 10 Feb 2010 15:01:53 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Alfred Perlstein In-Reply-To: <20100210191709.GD71374@elvis.mu.org> Message-ID: 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; format=flowed 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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:01:55 -0000 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... -- DE