Date: Thu, 11 Feb 2010 10:19:18 +0800 From: David Xu <davidxu@freebsd.org> To: Randall Stewart <rrs@lakerest.net> Cc: Daniel Eischen <deischen@freebsd.org>, threads@freebsd.org Subject: Re: Thinking about kqueue's and pthread_cond_wait Message-ID: <4B736926.3020102@freebsd.org> In-Reply-To: <327FA92C-5C58-449C-A8B5-DD1B4AC4A192@lakerest.net> References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210142917.GW71374@elvis.mu.org> <88D10D0C-0041-489C-BCCF-6F45431EC067@lakerest.net> <Pine.GSO.4.64.1002101146300.13656@sea.ntplx.net> <327FA92C-5C58-449C-A8B5-DD1B4AC4A192@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.. > That's why we have not done it, new requirements like your kqueue + condvar binding makes a shared public structure impossible, because once the structure is public, it is rather diffcult to change it to support new futures without create a new version of pthread APIs with symbol versioning, it is rather ugly. Current, we only makes semaphore to be sharable across processes to mimic some locking or waiting semantic. David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B736926.3020102>