From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 17:32:05 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 1DEDE1065670; Wed, 10 Feb 2010 17:32:05 +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 B5F778FC18; Wed, 10 Feb 2010 17:32:04 +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 o1AHW3fF017815; Wed, 10 Feb 2010 12:32:03 -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 12:32:03 -0500 (EST) Date: Wed, 10 Feb 2010 12:32:03 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Randall Stewart In-Reply-To: <327FA92C-5C58-449C-A8B5-DD1B4AC4A192@lakerest.net> Message-ID: References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210142917.GW71374@elvis.mu.org> <88D10D0C-0041-489C-BCCF-6F45431EC067@lakerest.net> <327FA92C-5C58-449C-A8B5-DD1B4AC4A192@lakerest.net> 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 17:32:05 -0000 On Wed, 10 Feb 2010, Randall Stewart wrote: > > On Feb 10, 2010, at 8:59 AM, Daniel Eischen wrote: > >> On Wed, 10 Feb 2010, Randall Stewart wrote: >> >>> Alfred: >>> >>> Basically I would like to have a dispatch/reactor loop that can >>> wait on multiple events. Including a condition variable that might >>> be in shared memory or for that matter some other thread awakening >>> it to do something without having to create a pipe and write/read >>> a byte. >>> >>> A peer process could also "wake" the condition variable and this >>> would then show up as an event in my dispatch loop, assuming the cond >>> variable and mutex are in shared memory that is... For example a >>> peer could plop some data in shared memory (via a shm queue or >>> some such other construct) and then do a cond_wake() and ta-da >>> coolness ;-) >> >> Is it really that much different than creating a pipe and >> adding it to the kevent list? It seems pretty straight forward >> to use a pipe rather than munge condition variables and mutexes >> into kqueue. Plus, we don't even support (yet) mutexes and >> condition variables in shared memory, and if we did, this >> solution wouldn't be too portable across different FreeBSD >> releases. >> > > > Hmm I thought someone said in 9 we are supporting shared memory > pthreads... which I was hopeful for.. since that would avoid > internal hacks.. So far only semaphores, but I believe David is working on mutexes and condition variables. But either way, that would only be a solution for 9. >> Whether you are using pthread_cond_signal() or write()'ing >> a byte to the special pipe, you are still calling in to the >> kernel to wake another thread stuck in kevent(). You could >> also send a signal to the thread stuck in kevent() if you >> wanted to wake it up (EVFILT_SIGNAL). > > But these are different things.. So are mutexes. But they can achieve what you want to achieve. All you want to do is wakeup a thread stuck in kevent(). Munging the pthread_ API is not a unified approach, IMHO. -- DE