From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 16:14:48 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 4BE36106568F for ; Wed, 10 Feb 2010 16:14:48 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 307608FC1E for ; Wed, 10 Feb 2010 16:14:47 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id E15971A3D37; Wed, 10 Feb 2010 08:14:47 -0800 (PST) Date: Wed, 10 Feb 2010 08:14:47 -0800 From: Alfred Perlstein To: Randall Stewart Message-ID: <20100210161447.GY71374@elvis.mu.org> References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210142917.GW71374@elvis.mu.org> <88D10D0C-0041-489C-BCCF-6F45431EC067@lakerest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <88D10D0C-0041-489C-BCCF-6F45431EC067@lakerest.net> User-Agent: Mutt/1.4.2.3i 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 16:14:48 -0000 Interesting, I had the same problem, specifically I wanted to have a thread that both selected on fds, but also selected on some queues. Because I had no way to hook my queue's condvar directly into select I had to implement the pipe technique you describe. I'd say go for it, sounds very useful. -Alfred * Randall Stewart [100210 07:39] 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 ;-) > > It would let you have say a single pool of threads handling your > reactor/dispatch loop.. Excessive threads are not a good thing so > being able to have one pool.. and not fork off a bunch of extra > threads is a "good" thing IMO.. > > > R > On Feb 10, 2010, at 6:29 AM, Alfred Perlstein wrote: > > >It sounds really interesting, do you have a particular use-case > >you can share that would show how to use this at a macro-level? > > > >Why would someone kqueue on multiple (or single) condvars? > > > >There's probably some exciting reasons why. > > > >-Alfred > > > >* Randall Stewart [100210 06:09] wrote: > >>All: > >> > >>I have once again come around to thinking about joining pthread > >>cond > >>waits and > >>kqueue's. > >> > >>After thinking about it, I think its doable.. with something > >>like a: > >> > >>pthread_cond_wait_kqueue_np(kev, cond, mtx, ucontext) > >> > >>Then you can use kev inside a kqueue i.e. > >>ret = kevent(kq, kev, 1, outkev, 1, NULL); > >> > >>Now when you saw the event: > >> if (kev.filter == EVFILT_UMTX){ /* not sure about the name > >> here */ > >> pthread_kqueue_cond_wait_ret_np(kev, cond, mtx, ucontext) > >> do_user_action(cond,mtx, ucontext); > >> } > >> > >>Which would fill in the cond/mtx and ucontext for the user. > >> > >>Now does this sound useful to anyone.. i.e. should I spend the > >>time > >>making it work? > >> > >>The only down side to this is that it would have to allocate > >>memory so > >>one would need to do a: > >> > >> pthread_kqueue_cond_wait_free_np(kev) > >> > >>After you were done.. and I think it would be best for this to > >>be a ONE_SHOT.. i.e. you have to re-arm it if the event > >>happens... > >>Of course until you free it that can be as simple as passing the > >>kev > >>back down again (i.e. no pthread_cond_wait_kqueue_np() needed). > >> > >>Comments? Thoughts? i.e. especially is it worthwhile doing? > >> > >> > >>Thanks > >> > >> > >>R > >>------------------------------ > >>Randall Stewart > >>803-317-4952 (cell) > >> > >>_______________________________________________ > >>freebsd-threads@freebsd.org mailing list > >>http://lists.freebsd.org/mailman/listinfo/freebsd-threads > >>To unsubscribe, send any mail to > >>"freebsd-threads-unsubscribe@freebsd.org " > > > >-- > >- Alfred Perlstein > >.- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 > >.- FreeBSD committer > > > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > 803-345-0391(direct) -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer