Date: Wed, 10 Feb 2010 11:59:26 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Randall Stewart <rrs@lakerest.net> Cc: threads@freebsd.org Subject: Re: Thinking about kqueue's and pthread_cond_wait Message-ID: <Pine.GSO.4.64.1002101146300.13656@sea.ntplx.net> In-Reply-To: <88D10D0C-0041-489C-BCCF-6F45431EC067@lakerest.net> References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210142917.GW71374@elvis.mu.org> <88D10D0C-0041-489C-BCCF-6F45431EC067@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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). -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1002101146300.13656>