Date: Wed, 10 Feb 2010 09:24:52 -0800 From: Randall Stewart <rrs@lakerest.net> To: Daniel Eischen <deischen@freebsd.org> Cc: threads@freebsd.org Subject: Re: Thinking about kqueue's and pthread_cond_wait Message-ID: <327FA92C-5C58-449C-A8B5-DD1B4AC4A192@lakerest.net> In-Reply-To: <Pine.GSO.4.64.1002101146300.13656@sea.ntplx.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.. > 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.. Far better to have a unified approach IMO. R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?327FA92C-5C58-449C-A8B5-DD1B4AC4A192>