From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 15:39:26 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 230DC1065676; Wed, 10 Feb 2010 15:39:26 +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 B88B58FC1D; Wed, 10 Feb 2010 15:39:25 +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 o1AFdJwh004716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Feb 2010 10:39:23 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <88D10D0C-0041-489C-BCCF-6F45431EC067@lakerest.net> From: Randall Stewart To: Alfred Perlstein In-Reply-To: <20100210142917.GW71374@elvis.mu.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 10 Feb 2010 07:39:12 -0800 References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210142917.GW71374@elvis.mu.org> 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 15:39:26 -0000 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)