From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 17:25:09 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 AA6A21065672; Wed, 10 Feb 2010 17:25:09 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 3CE3D8FC1A; Wed, 10 Feb 2010 17:25:09 +0000 (UTC) Received: from mobile-166-129-159-005.mycingular.net (mobile-166-129-159-005.mycingular.net [166.129.159.5] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o1AHP0ET009136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Feb 2010 12:25:07 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <327FA92C-5C58-449C-A8B5-DD1B4AC4A192@lakerest.net> From: Randall Stewart To: Daniel Eischen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 10 Feb 2010 09:24:52 -0800 References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210142917.GW71374@elvis.mu.org> <88D10D0C-0041-489C-BCCF-6F45431EC067@lakerest.net> X-Mailer: Apple Mail (2.936) 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 List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 17:25:09 -0000 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)