From owner-freebsd-threads@FreeBSD.ORG Mon Feb 8 11:07:06 2010 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5675110656C2 for ; Mon, 8 Feb 2010 11:07:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 459298FC13 for ; Mon, 8 Feb 2010 11:07:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o18B76WY087529 for ; Mon, 8 Feb 2010 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o18B75iD087527 for freebsd-threads@FreeBSD.org; Mon, 8 Feb 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Feb 2010 11:07:05 GMT Message-Id: <201002081107.o18B75iD087527@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org 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: Mon, 08 Feb 2010 11:07:06 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/143115 threads [patch] pthread_join() can return EOPNOTSUPP o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/141198 threads [libc] src/lib/libc/stdio does not properly initialize o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 p threa/135462 threads [PATCH] _thread_cleanupspecific() doesn't handle delet o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 44 problems total. From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 14:09:02 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 1AAD8106568B for ; Wed, 10 Feb 2010 14:09:02 +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 C420D8FC16 for ; Wed, 10 Feb 2010 14:09:01 +0000 (UTC) Received: from [192.168.2.224] (pool-96-249-204-75.snfcca.dsl-w.verizon.net [96.249.204.75]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o1AE8ws0001121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 10 Feb 2010 09:09:00 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> From: Randall Stewart To: threads@freebsd.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 06:08:53 -0800 X-Mailer: Apple Mail (2.936) Cc: Subject: 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 14:09:02 -0000 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) From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 14:46:16 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 4D2841065693 for ; Wed, 10 Feb 2010 14:46:16 +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 3EAF38FC16 for ; Wed, 10 Feb 2010 14:46:16 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 6F63E1A3E37; Wed, 10 Feb 2010 06:29:17 -0800 (PST) Date: Wed, 10 Feb 2010 06:29:17 -0800 From: Alfred Perlstein To: Randall Stewart Message-ID: <20100210142917.GW71374@elvis.mu.org> References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@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 14:46:16 -0000 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 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) 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 From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 16:59:28 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 A62EE106566B; Wed, 10 Feb 2010 16:59:28 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5F0D88FC16; Wed, 10 Feb 2010 16:59:27 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o1AGxQpc026759; Wed, 10 Feb 2010 11:59:26 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Wed, 10 Feb 2010 11:59:26 -0500 (EST) Date: Wed, 10 Feb 2010 11:59:26 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Randall Stewart In-Reply-To: <88D10D0C-0041-489C-BCCF-6F45431EC067@lakerest.net> Message-ID: 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; format=flowed 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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 16:59:28 -0000 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 From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 17:04:10 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 9FD1E106566B for ; Wed, 10 Feb 2010 17:04:10 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 61CE88FC13 for ; Wed, 10 Feb 2010 17:04:10 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o1AH49RC029979; Wed, 10 Feb 2010 12:04:09 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Wed, 10 Feb 2010 12:04:09 -0500 (EST) Date: Wed, 10 Feb 2010 12:04:09 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Randall Stewart In-Reply-To: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> Message-ID: References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 17:04:10 -0000 On Wed, 10 Feb 2010, Randall Stewart 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? Please don't mess with the pthread_ API like that :-) If you really want to munge them together, see my email to you a few weeks ago last time you brought it up. -- DE 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) From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 17:25:58 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 2D9B11065692; Wed, 10 Feb 2010 17:25:58 +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 9F25A8FC1B; Wed, 10 Feb 2010 17:25:57 +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 o1AHP0EU009136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Feb 2010 12:25:54 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> From: Randall Stewart To: Daniel Eischen In-Reply-To: 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 09:25:52 -0800 References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@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:58 -0000 On Feb 10, 2010, at 9:04 AM, Daniel Eischen wrote: > On Wed, 10 Feb 2010, Randall Stewart 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? > > Please don't mess with the pthread_ API like that :-) If you > really want to munge them together, see my email to you a few > weeks ago last time you brought it up.' If I remember right your email was basically don't do it... I will go dig through the archives and re-read it all. R > > -- > DE > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 17:32:05 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 1DEDE1065670; Wed, 10 Feb 2010 17:32:05 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id B5F778FC18; Wed, 10 Feb 2010 17:32:04 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o1AHW3fF017815; Wed, 10 Feb 2010 12:32:03 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Wed, 10 Feb 2010 12:32:03 -0500 (EST) Date: Wed, 10 Feb 2010 12:32:03 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Randall Stewart In-Reply-To: <327FA92C-5C58-449C-A8B5-DD1B4AC4A192@lakerest.net> Message-ID: References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210142917.GW71374@elvis.mu.org> <88D10D0C-0041-489C-BCCF-6F45431EC067@lakerest.net> <327FA92C-5C58-449C-A8B5-DD1B4AC4A192@lakerest.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 17:32:05 -0000 On Wed, 10 Feb 2010, Randall Stewart wrote: > > 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.. So far only semaphores, but I believe David is working on mutexes and condition variables. But either way, that would only be a solution for 9. >> 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.. So are mutexes. But they can achieve what you want to achieve. All you want to do is wakeup a thread stuck in kevent(). Munging the pthread_ API is not a unified approach, IMHO. -- DE From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 17:46:49 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 2A35C106566B for ; Wed, 10 Feb 2010 17:46:48 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C243D8FC18 for ; Wed, 10 Feb 2010 17:46:47 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o1AHkklO027458; Wed, 10 Feb 2010 12:46:46 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Wed, 10 Feb 2010 12:46:46 -0500 (EST) Date: Wed, 10 Feb 2010 12:46:46 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Randall Stewart In-Reply-To: <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> Message-ID: References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 17:46:49 -0000 On Wed, 10 Feb 2010, Randall Stewart wrote: > > On Feb 10, 2010, at 9:04 AM, Daniel Eischen wrote: > >> On Wed, 10 Feb 2010, Randall Stewart 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? >> >> Please don't mess with the pthread_ API like that :-) If you >> really want to munge them together, see my email to you a few >> weeks ago last time you brought it up.' > > If I remember right your email was basically don't do it... I will > go dig through the archives and re-read it all. No, it was to add an interface or two to the kqueue/kevent API, not to modify the pthread_ API (which shouldn't know anything about kqueues). I really think the OS is already given us the tools we need to do the job simply enough. You can easily use a pipe, socketpair, or EVFILT_SIGNAL to wakeup a thread stuck in kevent(). You can additionally use a mutex to protect data shared between thread waiting in kevent() and other threads. I don't see what problem this is trying to solve and I think whatever solution you come up with involving mutexes/CVs is not going to be any simpler and may even be more complex and messy. Mutexes and CVs are userland library thingies, not kernel entities. Yes, the umtx is a kernel entity, but it alone does not give you mutexes and CVs. So when you want to mix kqueues and mutexes/CVs, you are involving another userland library and this is what makes it messy. -- DE From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 18:07:58 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 462A610656A8; Wed, 10 Feb 2010 18:07:58 +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 EFD158FC16; Wed, 10 Feb 2010 18:07:57 +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 o1AI7ned011090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Feb 2010 13:07:56 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> From: Randall Stewart To: Daniel Eischen In-Reply-To: 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 10:07:43 -0800 References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@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 18:07:58 -0000 On Feb 10, 2010, at 9:46 AM, Daniel Eischen wrote: > On Wed, 10 Feb 2010, Randall Stewart wrote: > >> >> On Feb 10, 2010, at 9:04 AM, Daniel Eischen wrote: >> >>> On Wed, 10 Feb 2010, Randall Stewart 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? >>> Please don't mess with the pthread_ API like that :-) If you >>> really want to munge them together, see my email to you a few >>> weeks ago last time you brought it up.' >> >> If I remember right your email was basically don't do it... I will >> go dig through the archives and re-read it all. > > No, it was to add an interface or two to the kqueue/kevent API, not > to modify the pthread_ API (which shouldn't know anything about > kqueues). > > I really think the OS is already given us the tools we need to > do the job simply enough. You can easily use a pipe, socketpair, > or EVFILT_SIGNAL to wakeup a thread stuck in kevent(). You can > additionally use a mutex to protect data shared between thread > waiting in kevent() and other threads. > > I don't see what problem this is trying to solve and I think > whatever solution you come up with involving mutexes/CVs is > not going to be any simpler and may even be more complex and > messy. Mutexes and CVs are userland library thingies, not > kernel entities. Yes, the umtx is a kernel entity, but it > alone does not give you mutexes and CVs. So when you want > to mix kqueues and mutexes/CVs, you are involving another > userland library and this is what makes it messy. You suggested: kq = kqueue(); kq_obj = kq_create(kq, ...); kq_lock(&kq_obj); while (!P) { /* Atomically unlocks kq_obj and blocks. */ nevents = kq_wait(&kq_obj, ...); /* When you wakeup, kq_obj is locked again. */ } do_work(); But that does not satisfy anything but the condition variable. What would be nice is kq = kqueue(); /* sub to various events */ EV_SET(ev, ....); kevent(ev,...); Then in some nice loop where threads are waiting: while (notdone) { nev = kevent(kq, , ev); if (ev.fitler == EVFILTER_READ) { handle_the_read_thingy(ev); } else if (ev.filter == EVFILTER_COND) { lock_mutex(if needed) handle_condition_event(); } } One of the things I will note about a condition variable is that the downside is you ALWAYS have to have a mutex.. and not always do you need one... I have found multiple times in user apps where i am creating a mutex only for the benefit of the pthread_cond() api... sometimes just being woken up is enough ;-) R > > -- > DE > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 18:22:17 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 D9470106568F for ; Wed, 10 Feb 2010 18:22:17 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id ACAEE8FC18 for ; Wed, 10 Feb 2010 18:22:17 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o1AIMFDu020136; Wed, 10 Feb 2010 13:22:16 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Wed, 10 Feb 2010 13:22:16 -0500 (EST) Date: Wed, 10 Feb 2010 13:22:15 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Randall Stewart In-Reply-To: <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> Message-ID: References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 18:22:18 -0000 On Wed, 10 Feb 2010, Randall Stewart wrote: > > On Feb 10, 2010, at 9:46 AM, Daniel Eischen wrote: > >> On Wed, 10 Feb 2010, Randall Stewart wrote: >> >>> >>> On Feb 10, 2010, at 9:04 AM, Daniel Eischen wrote: >>> >>>> On Wed, 10 Feb 2010, Randall Stewart 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? >>>> Please don't mess with the pthread_ API like that :-) If you >>>> really want to munge them together, see my email to you a few >>>> weeks ago last time you brought it up.' >>> >>> If I remember right your email was basically don't do it... I will >>> go dig through the archives and re-read it all. >> >> No, it was to add an interface or two to the kqueue/kevent API, not >> to modify the pthread_ API (which shouldn't know anything about >> kqueues). >> >> I really think the OS is already given us the tools we need to >> do the job simply enough. You can easily use a pipe, socketpair, >> or EVFILT_SIGNAL to wakeup a thread stuck in kevent(). You can >> additionally use a mutex to protect data shared between thread >> waiting in kevent() and other threads. >> >> I don't see what problem this is trying to solve and I think >> whatever solution you come up with involving mutexes/CVs is >> not going to be any simpler and may even be more complex and >> messy. Mutexes and CVs are userland library thingies, not >> kernel entities. Yes, the umtx is a kernel entity, but it >> alone does not give you mutexes and CVs. So when you want >> to mix kqueues and mutexes/CVs, you are involving another >> userland library and this is what makes it messy. > > You suggested: > > kq = kqueue(); > kq_obj = kq_create(kq, ...); > kq_lock(&kq_obj); > while (!P) { > /* Atomically unlocks kq_obj and blocks. */ > nevents = kq_wait(&kq_obj, ...); > /* When you wakeup, kq_obj is locked again. */ > } > do_work(); > > > But that does not satisfy anything but the condition variable. What > would be nice is Yes, it does. You (the implementors of kq_create()) are suppose to maintain the mutex and/or CV inside the kq_obj thingie and hide it from the user of the interface. Whatever you need to lock and wait is embedded in kq_obj. You will have to do some of the same things that libthr does with umtx in pthread_mutex_{lock,unlock} and pthread_cond_{wait,signal,broadcast}. -- DE From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 18:49:16 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 2AA9D1065692 for ; Wed, 10 Feb 2010 18:49:16 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D89D88FC13 for ; Wed, 10 Feb 2010 18:49:15 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o1AIn488006729; Wed, 10 Feb 2010 13:49:04 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Wed, 10 Feb 2010 13:49:04 -0500 (EST) Date: Wed, 10 Feb 2010 13:49:04 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Randall Stewart In-Reply-To: <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> Message-ID: References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:49:16 -0000 On Wed, 10 Feb 2010, Randall Stewart wrote: > > > while (notdone) { > nev = kevent(kq, , ev); > if (ev.fitler == EVFILTER_READ) { > handle_the_read_thingy(ev); > } else if (ev.filter == EVFILTER_COND) { > lock_mutex(if needed) > handle_condition_event(); > } > } > > > One of the things I will note about a condition variable is that the downside > is > you ALWAYS have to have a mutex.. and not always do you need one... I have > found > multiple times in user apps where i am creating a mutex only for the benefit > of > the pthread_cond() api... sometimes just being woken up is enough ;-) [ I didn't see that you were waiting on multiple CVs... ] I don't understand why you need to wait on multiple condition variables. Either way, you have to maintain a queue of them along with their associated mutexes and then take some action unique to each one of them. What is the difference between that and maintaining a queue of some other thingies that maintain similar state data? -- DE From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 18:57:47 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 4D0A11065679 for ; Wed, 10 Feb 2010 18:57:47 +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 38C1C8FC19 for ; Wed, 10 Feb 2010 18:57:47 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id EFB701A3E8D; Wed, 10 Feb 2010 10:57:46 -0800 (PST) Date: Wed, 10 Feb 2010 10:57:46 -0800 From: Alfred Perlstein To: Daniel Eischen Message-ID: <20100210185746.GC71374@elvis.mu.org> References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 18:57:47 -0000 * Daniel Eischen [100210 10:50] wrote: > On Wed, 10 Feb 2010, Randall Stewart wrote: > > > > > > >while (notdone) { > > nev = kevent(kq, , ev); > > if (ev.fitler == EVFILTER_READ) { > > handle_the_read_thingy(ev); > > } else if (ev.filter == EVFILTER_COND) { > > lock_mutex(if needed) > > handle_condition_event(); > > } > >} > > > > > >One of the things I will note about a condition variable is that the > >downside is > >you ALWAYS have to have a mutex.. and not always do you need one... I have > >found > >multiple times in user apps where i am creating a mutex only for the > >benefit of > >the pthread_cond() api... sometimes just being woken up is enough ;-) > > [ I didn't see that you were waiting on multiple CVs... ] > > I don't understand why you need to wait on multiple > condition variables. Either way, you have to maintain > a queue of them along with their associated mutexes and > then take some action unique to each one of them. What > is the difference between that and maintaining a queue of > some other thingies that maintain similar state data? Developer convenience. If we offer a stable API and way of doing it right, then we offer a solid base for programs. By making users roll their own we have them duplicate code and introduce errors, in fact the idea of how to get this working (using a pipe(2) loop back) is so esoteric to likely block a significant portion of users from solving this problem at all. -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 19:06:43 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 399871065676; Wed, 10 Feb 2010 19:06:43 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D0F558FC13; Wed, 10 Feb 2010 19:06:42 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o1AJ6fZ6017759; Wed, 10 Feb 2010 14:06:41 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Wed, 10 Feb 2010 14:06:41 -0500 (EST) Date: Wed, 10 Feb 2010 14:06:41 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Alfred Perlstein In-Reply-To: <20100210185746.GC71374@elvis.mu.org> Message-ID: References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> <20100210185746.GC71374@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:06:43 -0000 On Wed, 10 Feb 2010, Alfred Perlstein wrote: > * Daniel Eischen [100210 10:50] wrote: >> On Wed, 10 Feb 2010, Randall Stewart wrote: >> >>> >>> >>> while (notdone) { >>> nev = kevent(kq, , ev); >>> if (ev.fitler == EVFILTER_READ) { >>> handle_the_read_thingy(ev); >>> } else if (ev.filter == EVFILTER_COND) { >>> lock_mutex(if needed) >>> handle_condition_event(); >>> } >>> } >>> >>> >>> One of the things I will note about a condition variable is that the >>> downside is >>> you ALWAYS have to have a mutex.. and not always do you need one... I have >>> found >>> multiple times in user apps where i am creating a mutex only for the >>> benefit of >>> the pthread_cond() api... sometimes just being woken up is enough ;-) >> >> [ I didn't see that you were waiting on multiple CVs... ] >> >> I don't understand why you need to wait on multiple >> condition variables. Either way, you have to maintain >> a queue of them along with their associated mutexes and >> then take some action unique to each one of them. What >> is the difference between that and maintaining a queue of >> some other thingies that maintain similar state data? > > Developer convenience. > > If we offer a stable API and way of doing it right, then we offer > a solid base for programs. By making users roll their own we have > them duplicate code and introduce errors, in fact the idea of how > to get this working (using a pipe(2) loop back) is so esoteric to > likely block a significant portion of users from solving this problem > at all. See the proposed solution hacking the pthread API and think twice about that. If you need a generic way of waiting and waking threads in kevent, then extend the kqueue/kevent interface to allow it. Add a userland struct kq_wait object along with EVFILT_KQ_WAIT, and a syscall to send wake up that event. -- DE From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 19:17:10 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 2F213106566B; Wed, 10 Feb 2010 19:17:10 +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 19DE68FC13; Wed, 10 Feb 2010 19:17:10 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 07D8B1A3D37; Wed, 10 Feb 2010 11:17:10 -0800 (PST) Date: Wed, 10 Feb 2010 11:17:09 -0800 From: Alfred Perlstein To: Daniel Eischen Message-ID: <20100210191709.GD71374@elvis.mu.org> References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> <20100210185746.GC71374@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 19:17:10 -0000 * Daniel Eischen [100210 11:06] wrote: > On Wed, 10 Feb 2010, Alfred Perlstein wrote: > > >* Daniel Eischen [100210 10:50] wrote: > >>On Wed, 10 Feb 2010, Randall Stewart wrote: > >> > >>> > >>> > >>>while (notdone) { > >>> nev = kevent(kq, , ev); > >>> if (ev.fitler == EVFILTER_READ) { > >>> handle_the_read_thingy(ev); > >>> } else if (ev.filter == EVFILTER_COND) { > >>> lock_mutex(if needed) > >>> handle_condition_event(); > >>> } > >>>} > >>> > >>> > >>>One of the things I will note about a condition variable is that the > >>>downside is > >>>you ALWAYS have to have a mutex.. and not always do you need one... I > >>>have > >>>found > >>>multiple times in user apps where i am creating a mutex only for the > >>>benefit of > >>>the pthread_cond() api... sometimes just being woken up is enough ;-) > >> > >>[ I didn't see that you were waiting on multiple CVs... ] > >> > >>I don't understand why you need to wait on multiple > >>condition variables. Either way, you have to maintain > >>a queue of them along with their associated mutexes and > >>then take some action unique to each one of them. What > >>is the difference between that and maintaining a queue of > >>some other thingies that maintain similar state data? > > > >Developer convenience. > > > >If we offer a stable API and way of doing it right, then we offer > >a solid base for programs. By making users roll their own we have > >them duplicate code and introduce errors, in fact the idea of how > >to get this working (using a pipe(2) loop back) is so esoteric to > >likely block a significant portion of users from solving this problem > >at all. > > See the proposed solution hacking the pthread API and think twice > about that. > > If you need a generic way of waiting and waking threads in kevent, > then extend the kqueue/kevent interface to allow it. Add a userland > struct kq_wait object along with EVFILT_KQ_WAIT, and a syscall to > send wake up that event. Again, this is not convenient. It is more complex and error prone for users. I will review the _additions_ to the pthreads API to see if they cause any performance issues for the "non-use" case. -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 20:01:55 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 B1930106566C; Wed, 10 Feb 2010 20:01:55 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 50E208FC13; Wed, 10 Feb 2010 20:01:54 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o1AK1rvk018657; Wed, 10 Feb 2010 15:01:53 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Wed, 10 Feb 2010 15:01:53 -0500 (EST) Date: Wed, 10 Feb 2010 15:01:53 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Alfred Perlstein In-Reply-To: <20100210191709.GD71374@elvis.mu.org> Message-ID: References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> <20100210185746.GC71374@elvis.mu.org> <20100210191709.GD71374@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:01:55 -0000 On Wed, 10 Feb 2010, Alfred Perlstein wrote: > * Daniel Eischen [100210 11:06] wrote: >> On Wed, 10 Feb 2010, Alfred Perlstein wrote: >> >>> * Daniel Eischen [100210 10:50] wrote: >>>> On Wed, 10 Feb 2010, Randall Stewart wrote: >>>> >>>>> >>>>> >>>>> while (notdone) { >>>>> nev = kevent(kq, , ev); >>>>> if (ev.fitler == EVFILTER_READ) { >>>>> handle_the_read_thingy(ev); >>>>> } else if (ev.filter == EVFILTER_COND) { >>>>> lock_mutex(if needed) >>>>> handle_condition_event(); >>>>> } >>>>> } >>>>> >>>>> >>>>> One of the things I will note about a condition variable is that the >>>>> downside is >>>>> you ALWAYS have to have a mutex.. and not always do you need one... I >>>>> have >>>>> found >>>>> multiple times in user apps where i am creating a mutex only for the >>>>> benefit of >>>>> the pthread_cond() api... sometimes just being woken up is enough ;-) >>>> >>>> [ I didn't see that you were waiting on multiple CVs... ] >>>> >>>> I don't understand why you need to wait on multiple >>>> condition variables. Either way, you have to maintain >>>> a queue of them along with their associated mutexes and >>>> then take some action unique to each one of them. What >>>> is the difference between that and maintaining a queue of >>>> some other thingies that maintain similar state data? >>> >>> Developer convenience. >>> >>> If we offer a stable API and way of doing it right, then we offer >>> a solid base for programs. By making users roll their own we have >>> them duplicate code and introduce errors, in fact the idea of how >>> to get this working (using a pipe(2) loop back) is so esoteric to >>> likely block a significant portion of users from solving this problem >>> at all. >> >> See the proposed solution hacking the pthread API and think twice >> about that. >> >> If you need a generic way of waiting and waking threads in kevent, >> then extend the kqueue/kevent interface to allow it. Add a userland >> struct kq_wait object along with EVFILT_KQ_WAIT, and a syscall to >> send wake up that event. > > Again, this is not convenient. It is more complex and error prone > for users. I strongly disagree. Using mutexes and condition variables in the proper way is not as easy as it sounds, let alone trying to mix them as userland thingies into kqueue. I will strongly oppose this... -- DE From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 20:06:31 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 834DE1065692; Wed, 10 Feb 2010 20:06:31 +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 6C5D68FC17; Wed, 10 Feb 2010 20:06:31 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 21D251A3E92; Wed, 10 Feb 2010 12:06:31 -0800 (PST) Date: Wed, 10 Feb 2010 12:06:31 -0800 From: Alfred Perlstein To: Daniel Eischen Message-ID: <20100210200631.GE71374@elvis.mu.org> References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> <20100210185746.GC71374@elvis.mu.org> <20100210191709.GD71374@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 20:06:31 -0000 * Daniel Eischen [100210 12:01] wrote: > On Wed, 10 Feb 2010, Alfred Perlstein wrote: > > >* Daniel Eischen [100210 11:06] wrote: > >>On Wed, 10 Feb 2010, Alfred Perlstein wrote: > >> > >>>* Daniel Eischen [100210 10:50] wrote: > >>>>On Wed, 10 Feb 2010, Randall Stewart wrote: > >>>> > >>>>> > >>>>> > >>>>>while (notdone) { > >>>>> nev = kevent(kq, , ev); > >>>>> if (ev.fitler == EVFILTER_READ) { > >>>>> handle_the_read_thingy(ev); > >>>>> } else if (ev.filter == EVFILTER_COND) { > >>>>> lock_mutex(if needed) > >>>>> handle_condition_event(); > >>>>> } > >>>>>} > >>>>> > >>>>> > >>>>>One of the things I will note about a condition variable is that the > >>>>>downside is > >>>>>you ALWAYS have to have a mutex.. and not always do you need one... I > >>>>>have > >>>>>found > >>>>>multiple times in user apps where i am creating a mutex only for the > >>>>>benefit of > >>>>>the pthread_cond() api... sometimes just being woken up is enough ;-) > >>>> > >>>>[ I didn't see that you were waiting on multiple CVs... ] > >>>> > >>>>I don't understand why you need to wait on multiple > >>>>condition variables. Either way, you have to maintain > >>>>a queue of them along with their associated mutexes and > >>>>then take some action unique to each one of them. What > >>>>is the difference between that and maintaining a queue of > >>>>some other thingies that maintain similar state data? > >>> > >>>Developer convenience. > >>> > >>>If we offer a stable API and way of doing it right, then we offer > >>>a solid base for programs. By making users roll their own we have > >>>them duplicate code and introduce errors, in fact the idea of how > >>>to get this working (using a pipe(2) loop back) is so esoteric to > >>>likely block a significant portion of users from solving this problem > >>>at all. > >> > >>See the proposed solution hacking the pthread API and think twice > >>about that. > >> > >>If you need a generic way of waiting and waking threads in kevent, > >>then extend the kqueue/kevent interface to allow it. Add a userland > >>struct kq_wait object along with EVFILT_KQ_WAIT, and a syscall to > >>send wake up that event. > > > >Again, this is not convenient. It is more complex and error prone > >for users. > > I strongly disagree. Using mutexes and condition variables in the > proper way is not as easy as it sounds, let alone trying to mix > them as userland thingies into kqueue. > > I will strongly oppose this... Well then you "win". I have no desire to engage in such discussion. I do hope that when you see this facility leveraged elsewhere for an application that you reflect on this conversation and think back on it the next time an opportunity presents itself to lead in functionality. -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From owner-freebsd-threads@FreeBSD.ORG Wed Feb 10 20:18:41 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 7D13D106568B; Wed, 10 Feb 2010 20:18:41 +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 3013F8FC28; Wed, 10 Feb 2010 20:18:41 +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 o1AKIWhb016646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Feb 2010 15:18:39 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: From: Randall Stewart To: Alfred Perlstein In-Reply-To: <20100210200631.GE71374@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 12:18:23 -0800 References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> <20100210185746.GC71374@elvis.mu.org> <20100210191709.GD71374@elvis.mu.org> <20100210200631.GE71374@elvis.mu.org> X-Mailer: Apple Mail (2.936) Cc: Daniel Eischen , 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 20:18:41 -0000 On Feb 10, 2010, at 12:06 PM, Alfred Perlstein wrote: > * Daniel Eischen [100210 12:01] wrote: >> On Wed, 10 Feb 2010, Alfred Perlstein wrote: >> >>> * Daniel Eischen [100210 11:06] wrote: >>>> On Wed, 10 Feb 2010, Alfred Perlstein wrote: >>>> >>>>> * Daniel Eischen [100210 10:50] wrote: >>>>>> On Wed, 10 Feb 2010, Randall Stewart wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> while (notdone) { >>>>>>> nev = kevent(kq, , ev); >>>>>>> if (ev.fitler == EVFILTER_READ) { >>>>>>> handle_the_read_thingy(ev); >>>>>>> } else if (ev.filter == EVFILTER_COND) { >>>>>>> lock_mutex(if needed) >>>>>>> handle_condition_event(); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> One of the things I will note about a condition variable is >>>>>>> that the >>>>>>> downside is >>>>>>> you ALWAYS have to have a mutex.. and not always do you need >>>>>>> one... I >>>>>>> have >>>>>>> found >>>>>>> multiple times in user apps where i am creating a mutex only >>>>>>> for the >>>>>>> benefit of >>>>>>> the pthread_cond() api... sometimes just being woken up is >>>>>>> enough ;-) >>>>>> >>>>>> [ I didn't see that you were waiting on multiple CVs... ] >>>>>> >>>>>> I don't understand why you need to wait on multiple >>>>>> condition variables. Either way, you have to maintain >>>>>> a queue of them along with their associated mutexes and >>>>>> then take some action unique to each one of them. What >>>>>> is the difference between that and maintaining a queue of >>>>>> some other thingies that maintain similar state data? >>>>> >>>>> Developer convenience. >>>>> >>>>> If we offer a stable API and way of doing it right, then we offer >>>>> a solid base for programs. By making users roll their own we have >>>>> them duplicate code and introduce errors, in fact the idea of how >>>>> to get this working (using a pipe(2) loop back) is so esoteric to >>>>> likely block a significant portion of users from solving this >>>>> problem >>>>> at all. >>>> >>>> See the proposed solution hacking the pthread API and think twice >>>> about that. >>>> >>>> If you need a generic way of waiting and waking threads in kevent, >>>> then extend the kqueue/kevent interface to allow it. Add a >>>> userland >>>> struct kq_wait object along with EVFILT_KQ_WAIT, and a syscall to >>>> send wake up that event. >>> >>> Again, this is not convenient. It is more complex and error prone >>> for users. >> >> I strongly disagree. Using mutexes and condition variables in the >> proper way is not as easy as it sounds, let alone trying to mix >> them as userland thingies into kqueue. >> >> I will strongly oppose this... > > Well then you "win". I have no desire to engage in such discussion. > > I do hope that when you see this facility leveraged elsewhere for > an application that you reflect on this conversation and think back > on it the next time an opportunity presents itself to lead in > functionality. > Alfred: I have to say lead would only be in the *nix domain.. the windows world (dare I say that) has had the ability to mix things like condition variables and fd's for ages.. or at least so I have been told (I have never coded in windows)... But it would be nice to have a similar ability in FreeBSD.. but with DE so against it I will just find another way .. I guess what will happen is I will end up creating my own condition variable. I have never been a fan of the mutex tied to it... so I may not build that unless folks ask for it ;-) (I usually tend to be receptive to new features).... R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 00:11:07 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 EF2F11065763; Thu, 11 Feb 2010 00:11:07 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id A4D878FC0A; Thu, 11 Feb 2010 00:11:07 +0000 (UTC) Received: from [10.93.17.21] (mobile-166-137-136-225.mycingular.net [166.137.136.225]) (authenticated bits=0) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o1B0B0ck016893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Feb 2010 19:11:02 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Wed, 10 Feb 2010 19:11:05 -0500 (EST) References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> <20100210185746.GC71374@elvis.mu.org> <20100210191709.GD71374@elvis.mu.org> <20100210200631.GE71374@elvis.mu.org> Message-Id: <7EDE50FA-DE52-46C0-B88A-BCA9CBF934A6@vigrid.com> From: Daniel Eischen To: Alfred Perlstein In-Reply-To: <20100210200631.GE71374@elvis.mu.org> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Wed, 10 Feb 2010 19:10:53 -0500 Cc: Daniel Eischen , "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: Thu, 11 Feb 2010 00:11:08 -0000 On Feb 10, 2010, at 3:06 PM, Alfred Perlstein wrote: > * Daniel Eischen [100210 12:01] wrote: >> >> >> I strongly disagree. Using mutexes and condition variables in the >> proper way is not as easy as it sounds, let alone trying to mix >> them as userland thingies into kqueue. >> >> I will strongly oppose this... > > Well then you "win". I have no desire to engage in such discussion. > > I do hope that when you see this facility leveraged elsewhere for > an application that you reflect on this conversation and think back > on it the next time an opportunity presents itself to lead in > functionality. Don't misunderstand me, I just don't think running around the tree and adapting all the userland leaves to kqueue-isize them is the right approach. IMHO, it's better to extend the kqueue/kevent mechanism to allow a generic object to be added to the event list and the kqueue to be signaled from userland. All the pthread and semaphore functions are userland operations that also rely on userland structures anyway. -- DE From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 00:12:21 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 C9A72106575A; Thu, 11 Feb 2010 00:12:21 +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 B38998FC16; Thu, 11 Feb 2010 00:12:21 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 865431A3D25; Wed, 10 Feb 2010 16:12:21 -0800 (PST) Date: Wed, 10 Feb 2010 16:12:21 -0800 From: Alfred Perlstein To: Daniel Eischen Message-ID: <20100211001221.GN71374@elvis.mu.org> References: <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> <07AA24BB-DA26-406A-B24F-59E0CB36FEBE@lakerest.net> <20100210185746.GC71374@elvis.mu.org> <20100210191709.GD71374@elvis.mu.org> <20100210200631.GE71374@elvis.mu.org> <7EDE50FA-DE52-46C0-B88A-BCA9CBF934A6@vigrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7EDE50FA-DE52-46C0-B88A-BCA9CBF934A6@vigrid.com> User-Agent: Mutt/1.4.2.3i Cc: Daniel Eischen , "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: Thu, 11 Feb 2010 00:12:21 -0000 * Daniel Eischen [100210 16:11] wrote: > On Feb 10, 2010, at 3:06 PM, Alfred Perlstein > wrote: > > >* Daniel Eischen [100210 12:01] wrote: > >> > >> > >>I strongly disagree. Using mutexes and condition variables in the > >>proper way is not as easy as it sounds, let alone trying to mix > >>them as userland thingies into kqueue. > >> > >>I will strongly oppose this... > > > >Well then you "win". I have no desire to engage in such discussion. > > > >I do hope that when you see this facility leveraged elsewhere for > >an application that you reflect on this conversation and think back > >on it the next time an opportunity presents itself to lead in > >functionality. > > Don't misunderstand me, I just don't think running around the tree and > adapting all the userland leaves to kqueue-isize them is the right > approach. IMHO, it's better to extend the kqueue/kevent mechanism to > allow a generic object to be added to the event list and the kqueue to > be signaled from userland. All the pthread and semaphore functions > are userland operations that also rely on userland structures anyway. If you can show Randall a way to do this that will serve for his proposed purpose then we might have a win here. -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 02:19:21 2010 Return-Path: Delivered-To: threads@freebsd.org Received: from alona.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 480A61065695; Thu, 11 Feb 2010 02:19:20 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <4B736926.3020102@freebsd.org> Date: Thu, 11 Feb 2010 10:19:18 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.21 (X11/20090522) MIME-Version: 1.0 To: Randall Stewart References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210142917.GW71374@elvis.mu.org> <88D10D0C-0041-489C-BCCF-6F45431EC067@lakerest.net> <327FA92C-5C58-449C-A8B5-DD1B4AC4A192@lakerest.net> In-Reply-To: <327FA92C-5C58-449C-A8B5-DD1B4AC4A192@lakerest.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , 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: Thu, 11 Feb 2010 02:19:21 -0000 Randall Stewart wrote: > > 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.. > That's why we have not done it, new requirements like your kqueue + condvar binding makes a shared public structure impossible, because once the structure is public, it is rather diffcult to change it to support new futures without create a new version of pthread APIs with symbol versioning, it is rather ugly. Current, we only makes semaphore to be sharable across processes to mimic some locking or waiting semantic. David Xu From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 14:03:57 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19DC1106566B; Thu, 11 Feb 2010 14:03:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DC5A38FC15; Thu, 11 Feb 2010 14:03:56 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7633046B2C; Thu, 11 Feb 2010 09:03:56 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 95EF08A021; Thu, 11 Feb 2010 09:03:55 -0500 (EST) From: John Baldwin To: freebsd-threads@freebsd.org, Daniel Eischen Date: Thu, 11 Feb 2010 08:54:59 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <3CF3033E-FD13-405B-9DC6-DDE9DF4FBF37@lakerest.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002110854.59265.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 11 Feb 2010 09:03:55 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: 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: Thu, 11 Feb 2010 14:03:57 -0000 On Wednesday 10 February 2010 12:46:46 pm Daniel Eischen wrote: > On Wed, 10 Feb 2010, Randall Stewart wrote: > > > > > On Feb 10, 2010, at 9:04 AM, Daniel Eischen wrote: > > > >> On Wed, 10 Feb 2010, Randall Stewart 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? > >> > >> Please don't mess with the pthread_ API like that :-) If you > >> really want to munge them together, see my email to you a few > >> weeks ago last time you brought it up.' > > > > If I remember right your email was basically don't do it... I will > > go dig through the archives and re-read it all. > > No, it was to add an interface or two to the kqueue/kevent API, not > to modify the pthread_ API (which shouldn't know anything about > kqueues). > > I really think the OS is already given us the tools we need to > do the job simply enough. You can easily use a pipe, socketpair, > or EVFILT_SIGNAL to wakeup a thread stuck in kevent(). You can > additionally use a mutex to protect data shared between thread > waiting in kevent() and other threads. > > I don't see what problem this is trying to solve and I think > whatever solution you come up with involving mutexes/CVs is > not going to be any simpler and may even be more complex and > messy. Mutexes and CVs are userland library thingies, not > kernel entities. Yes, the umtx is a kernel entity, but it > alone does not give you mutexes and CVs. So when you want > to mix kqueues and mutexes/CVs, you are involving another > userland library and this is what makes it messy. He wants something like 'WaitForMultipleObjects()' in NT. The fact that these are userland primitives is _precisely_ why I think it belongs in the pthread library. What I think is that you want a pthread primitive that is a wrapper around a kqueue. Something like: /* A lot like a 'struct event' */ struct pthread_event { }; /* Is actually an int to hold a kqueue fd. */ pthread_event_queue_t; /* Calls kqueue() to create the event. */ pthread_event_queue_init(); /* Similar to the kevent() call, but works with 'struct pthread_event' arrays instead of 'struct event' arrays. Internally, it maps 'struct pthread_event' objects to 'struct event' objects to pass to an internal call to kevent(). This code can take care of mapping requests to wait for a cv or mutex to the appropriate EVFILT_UMTX w/o exposing the EVFILT_UMTX implementation details to userland. */ pthread_event_queue_wait(); The user code model would look something like this: pthread_event_queue_t queue; struct pthread_event event; pthread_cond_t cv /* some condition variable */ int fd; /* some socket */ pthread_event_queue_init(&queue); /* This is like EV_SET, maybe you would have a EVQ_SET? */ event.filter = READ; event.fd = fd; event.flags = EV_ADD; /* Register socket. */ pthread_event_queue_wait(queue, NULL, 0, &event, 1, NULL); event.filter = CONDVAR; event.cv = cv; event.flags = EV_ADD; /* Register condvar. */ pthread_event_queue_wait(queue, NULL, 0, &event, 1, NULL); /* Wait for something to happen. */ for (;;) { pthread_event_queue_wait(queue, &event, 1, NULL, 0, NULL); switch (event.filter) { case READ: /* socket is ready to read */ case CV: /* cv is signalled */ } } To be honest, I find semaphores and mutexes more compelling than condvars for this sort of thing (you would do a try-lock to acquire the mutex or semaphore perhaps when it is signalled). If you supported thread objects you could do a pthread_join() after a thread exits. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 14:03:57 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3EB11065676; Thu, 11 Feb 2010 14:03:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B2D758FC16; Thu, 11 Feb 2010 14:03:57 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 64E6A46B53; Thu, 11 Feb 2010 09:03:57 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id B5A7A8A024; Thu, 11 Feb 2010 09:03:56 -0500 (EST) From: John Baldwin To: freebsd-threads@freebsd.org Date: Thu, 11 Feb 2010 08:57:12 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210200631.GE71374@elvis.mu.org> <7EDE50FA-DE52-46C0-B88A-BCA9CBF934A6@vigrid.com> In-Reply-To: <7EDE50FA-DE52-46C0-B88A-BCA9CBF934A6@vigrid.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002110857.12206.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 11 Feb 2010 09:03:56 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Daniel Eischen , "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: Thu, 11 Feb 2010 14:03:58 -0000 On Wednesday 10 February 2010 7:10:53 pm Daniel Eischen wrote: > On Feb 10, 2010, at 3:06 PM, Alfred Perlstein > wrote: > > > * Daniel Eischen [100210 12:01] wrote: > >> > >> > >> I strongly disagree. Using mutexes and condition variables in the > >> proper way is not as easy as it sounds, let alone trying to mix > >> them as userland thingies into kqueue. > >> > >> I will strongly oppose this... > > > > Well then you "win". I have no desire to engage in such discussion. > > > > I do hope that when you see this facility leveraged elsewhere for > > an application that you reflect on this conversation and think back > > on it the next time an opportunity presents itself to lead in > > functionality. > > Don't misunderstand me, I just don't think running around the tree and > adapting all the userland leaves to kqueue-isize them is the right > approach. IMHO, it's better to extend the kqueue/kevent mechanism to > allow a generic object to be added to the event list and the kqueue to > be signaled from userland. All the pthread and semaphore functions > are userland operations that also rely on userland structures anyway. kqueue/kevent already support that via EVFILT_USER, and Apple's GCD depends on this extensively. However, my point from my earlier post still stands and I think it is the right way to implement something like NT's WaitForMultipleObjects(). -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 14:03:57 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 E3EB11065676; Thu, 11 Feb 2010 14:03:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B2D758FC16; Thu, 11 Feb 2010 14:03:57 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 64E6A46B53; Thu, 11 Feb 2010 09:03:57 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id B5A7A8A024; Thu, 11 Feb 2010 09:03:56 -0500 (EST) From: John Baldwin To: freebsd-threads@freebsd.org Date: Thu, 11 Feb 2010 08:57:12 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210200631.GE71374@elvis.mu.org> <7EDE50FA-DE52-46C0-B88A-BCA9CBF934A6@vigrid.com> In-Reply-To: <7EDE50FA-DE52-46C0-B88A-BCA9CBF934A6@vigrid.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002110857.12206.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 11 Feb 2010 09:03:56 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Daniel Eischen , "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: Thu, 11 Feb 2010 14:03:58 -0000 On Wednesday 10 February 2010 7:10:53 pm Daniel Eischen wrote: > On Feb 10, 2010, at 3:06 PM, Alfred Perlstein > wrote: > > > * Daniel Eischen [100210 12:01] wrote: > >> > >> > >> I strongly disagree. Using mutexes and condition variables in the > >> proper way is not as easy as it sounds, let alone trying to mix > >> them as userland thingies into kqueue. > >> > >> I will strongly oppose this... > > > > Well then you "win". I have no desire to engage in such discussion. > > > > I do hope that when you see this facility leveraged elsewhere for > > an application that you reflect on this conversation and think back > > on it the next time an opportunity presents itself to lead in > > functionality. > > Don't misunderstand me, I just don't think running around the tree and > adapting all the userland leaves to kqueue-isize them is the right > approach. IMHO, it's better to extend the kqueue/kevent mechanism to > allow a generic object to be added to the event list and the kqueue to > be signaled from userland. All the pthread and semaphore functions > are userland operations that also rely on userland structures anyway. kqueue/kevent already support that via EVFILT_USER, and Apple's GCD depends on this extensively. However, my point from my earlier post still stands and I think it is the right way to implement something like NT's WaitForMultipleObjects(). -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 15:36:50 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 A20771065693; Thu, 11 Feb 2010 15:36:50 +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 5089A8FC08; Thu, 11 Feb 2010 15:36:50 +0000 (UTC) Received: from mobile-166-129-022-112.mycingular.net (mobile-166-129-022-112.mycingular.net [166.129.22.112] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o1BFaffa063281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Feb 2010 10:36:47 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <3071EDFE-A83D-47E7-B1CA-110EDB7F7BF6@lakerest.net> From: Randall Stewart To: John Baldwin In-Reply-To: <201002110857.12206.jhb@freebsd.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: Thu, 11 Feb 2010 07:36:34 -0800 References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210200631.GE71374@elvis.mu.org> <7EDE50FA-DE52-46C0-B88A-BCA9CBF934A6@vigrid.com> <201002110857.12206.jhb@freebsd.org> X-Mailer: Apple Mail (2.936) Cc: Daniel Eischen , "threads@freebsd.org" , freebsd-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: Thu, 11 Feb 2010 15:36:50 -0000 On Feb 11, 2010, at 5:57 AM, John Baldwin wrote: >> > > kqueue/kevent already support that via EVFILT_USER, and Apple's GCD > depends on > this extensively. However, my point from my earlier post still > stands and I > think it is the right way to implement something like NT's > WaitForMultipleObjects(). > > -- > John Baldwin > _______________________________________________ > 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 > " > John: Is this being MFC'd to 8? I have an 8.0 machine at work where I am doing a lot of this userland stuff.. and the EVFILT_USER is not present but precisely what I need. R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 15:36:50 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A20771065693; Thu, 11 Feb 2010 15:36:50 +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 5089A8FC08; Thu, 11 Feb 2010 15:36:50 +0000 (UTC) Received: from mobile-166-129-022-112.mycingular.net (mobile-166-129-022-112.mycingular.net [166.129.22.112] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o1BFaffa063281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Feb 2010 10:36:47 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <3071EDFE-A83D-47E7-B1CA-110EDB7F7BF6@lakerest.net> From: Randall Stewart To: John Baldwin In-Reply-To: <201002110857.12206.jhb@freebsd.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: Thu, 11 Feb 2010 07:36:34 -0800 References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210200631.GE71374@elvis.mu.org> <7EDE50FA-DE52-46C0-B88A-BCA9CBF934A6@vigrid.com> <201002110857.12206.jhb@freebsd.org> X-Mailer: Apple Mail (2.936) Cc: Daniel Eischen , "threads@freebsd.org" , freebsd-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: Thu, 11 Feb 2010 15:36:50 -0000 On Feb 11, 2010, at 5:57 AM, John Baldwin wrote: >> > > kqueue/kevent already support that via EVFILT_USER, and Apple's GCD > depends on > this extensively. However, my point from my earlier post still > stands and I > think it is the right way to implement something like NT's > WaitForMultipleObjects(). > > -- > John Baldwin > _______________________________________________ > 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 > " > John: Is this being MFC'd to 8? I have an 8.0 machine at work where I am doing a lot of this userland stuff.. and the EVFILT_USER is not present but precisely what I need. R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 16:09:35 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 D45C2106566B; Thu, 11 Feb 2010 16:09:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A36BD8FC13; Thu, 11 Feb 2010 16:09:35 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3BA0D46B58; Thu, 11 Feb 2010 11:09:35 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 674028A01F; Thu, 11 Feb 2010 11:09:34 -0500 (EST) From: John Baldwin To: Randall Stewart Date: Thu, 11 Feb 2010 11:08:31 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <201002110857.12206.jhb@freebsd.org> <3071EDFE-A83D-47E7-B1CA-110EDB7F7BF6@lakerest.net> In-Reply-To: <3071EDFE-A83D-47E7-B1CA-110EDB7F7BF6@lakerest.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002111108.31938.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 11 Feb 2010 11:09:34 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Daniel Eischen , "threads@freebsd.org" , freebsd-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: Thu, 11 Feb 2010 16:09:35 -0000 On Thursday 11 February 2010 10:36:34 am Randall Stewart wrote: > > On Feb 11, 2010, at 5:57 AM, John Baldwin wrote: > > >> > > > > kqueue/kevent already support that via EVFILT_USER, and Apple's GCD > > depends on > > this extensively. However, my point from my earlier post still > > stands and I > > think it is the right way to implement something like NT's > > WaitForMultipleObjects(). > > > > -- > > John Baldwin > > _______________________________________________ > > 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 > > " > > > > > John: > > Is this being MFC'd to 8? > > I have an 8.0 machine at work where I am doing a lot of this userland > stuff.. and the > EVFILT_USER is not present but precisely what I need. It is in stable/8 I thought, just not 8.0 release. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 16:09:35 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D45C2106566B; Thu, 11 Feb 2010 16:09:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A36BD8FC13; Thu, 11 Feb 2010 16:09:35 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3BA0D46B58; Thu, 11 Feb 2010 11:09:35 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 674028A01F; Thu, 11 Feb 2010 11:09:34 -0500 (EST) From: John Baldwin To: Randall Stewart Date: Thu, 11 Feb 2010 11:08:31 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <201002110857.12206.jhb@freebsd.org> <3071EDFE-A83D-47E7-B1CA-110EDB7F7BF6@lakerest.net> In-Reply-To: <3071EDFE-A83D-47E7-B1CA-110EDB7F7BF6@lakerest.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002111108.31938.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 11 Feb 2010 11:09:34 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Daniel Eischen , "threads@freebsd.org" , freebsd-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: Thu, 11 Feb 2010 16:09:35 -0000 On Thursday 11 February 2010 10:36:34 am Randall Stewart wrote: > > On Feb 11, 2010, at 5:57 AM, John Baldwin wrote: > > >> > > > > kqueue/kevent already support that via EVFILT_USER, and Apple's GCD > > depends on > > this extensively. However, my point from my earlier post still > > stands and I > > think it is the right way to implement something like NT's > > WaitForMultipleObjects(). > > > > -- > > John Baldwin > > _______________________________________________ > > 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 > > " > > > > > John: > > Is this being MFC'd to 8? > > I have an 8.0 machine at work where I am doing a lot of this userland > stuff.. and the > EVFILT_USER is not present but precisely what I need. It is in stable/8 I thought, just not 8.0 release. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 16:49:04 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F14FB106566C; Thu, 11 Feb 2010 16:49:04 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 91BE58FC1D; Thu, 11 Feb 2010 16:49:04 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o1BGn3Bw007363; Thu, 11 Feb 2010 11:49:03 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Thu, 11 Feb 2010 11:49:03 -0500 (EST) Date: Thu, 11 Feb 2010 11:49:03 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <201002110857.12206.jhb@freebsd.org> Message-ID: References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210200631.GE71374@elvis.mu.org> <7EDE50FA-DE52-46C0-B88A-BCA9CBF934A6@vigrid.com> <201002110857.12206.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "threads@freebsd.org" , freebsd-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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 16:49:05 -0000 On Thu, 11 Feb 2010, John Baldwin wrote: > On Wednesday 10 February 2010 7:10:53 pm Daniel Eischen wrote: >> On Feb 10, 2010, at 3:06 PM, Alfred Perlstein >> wrote: >> >>> * Daniel Eischen [100210 12:01] wrote: >>>> >>>> >>>> I strongly disagree. Using mutexes and condition variables in the >>>> proper way is not as easy as it sounds, let alone trying to mix >>>> them as userland thingies into kqueue. >>>> >>>> I will strongly oppose this... >>> >>> Well then you "win". I have no desire to engage in such discussion. >>> >>> I do hope that when you see this facility leveraged elsewhere for >>> an application that you reflect on this conversation and think back >>> on it the next time an opportunity presents itself to lead in >>> functionality. >> >> Don't misunderstand me, I just don't think running around the tree and >> adapting all the userland leaves to kqueue-isize them is the right >> approach. IMHO, it's better to extend the kqueue/kevent mechanism to >> allow a generic object to be added to the event list and the kqueue to >> be signaled from userland. All the pthread and semaphore functions >> are userland operations that also rely on userland structures anyway. > > kqueue/kevent already support that via EVFILT_USER, and Apple's GCD depends on > this extensively. However, my point from my earlier post still stands and I > think it is the right way to implement something like NT's > WaitForMultipleObjects(). I guess that didn't exist in my 9.0-current that I looked at, so I replied privately with something very similar ;-) With this one could wrap pthread objects, semaphores, etc. The wrapper functions would have to additionally call kevent() to trigger the event if the object was being waited on in a kqueue, as in: typedef struct { #define MY_MTX_IN_KQUEUE 0x0001 int flags; pthread_mutex_t mutex; } my_pthread_mutex_t; my_pthread_mutex_unlock(my_pthread_mutex_t *m) { if (m->flags & MY_MTX_IN_KQUEUE) != 0) { /* Trigger the event. */ kevent(...); } ret = pthread_mutex_unlock(m->mutex); } -- DE From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 16:49:04 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 F14FB106566C; Thu, 11 Feb 2010 16:49:04 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 91BE58FC1D; Thu, 11 Feb 2010 16:49:04 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o1BGn3Bw007363; Thu, 11 Feb 2010 11:49:03 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Thu, 11 Feb 2010 11:49:03 -0500 (EST) Date: Thu, 11 Feb 2010 11:49:03 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <201002110857.12206.jhb@freebsd.org> Message-ID: References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <20100210200631.GE71374@elvis.mu.org> <7EDE50FA-DE52-46C0-B88A-BCA9CBF934A6@vigrid.com> <201002110857.12206.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "threads@freebsd.org" , freebsd-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 Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 16:49:05 -0000 On Thu, 11 Feb 2010, John Baldwin wrote: > On Wednesday 10 February 2010 7:10:53 pm Daniel Eischen wrote: >> On Feb 10, 2010, at 3:06 PM, Alfred Perlstein >> wrote: >> >>> * Daniel Eischen [100210 12:01] wrote: >>>> >>>> >>>> I strongly disagree. Using mutexes and condition variables in the >>>> proper way is not as easy as it sounds, let alone trying to mix >>>> them as userland thingies into kqueue. >>>> >>>> I will strongly oppose this... >>> >>> Well then you "win". I have no desire to engage in such discussion. >>> >>> I do hope that when you see this facility leveraged elsewhere for >>> an application that you reflect on this conversation and think back >>> on it the next time an opportunity presents itself to lead in >>> functionality. >> >> Don't misunderstand me, I just don't think running around the tree and >> adapting all the userland leaves to kqueue-isize them is the right >> approach. IMHO, it's better to extend the kqueue/kevent mechanism to >> allow a generic object to be added to the event list and the kqueue to >> be signaled from userland. All the pthread and semaphore functions >> are userland operations that also rely on userland structures anyway. > > kqueue/kevent already support that via EVFILT_USER, and Apple's GCD depends on > this extensively. However, my point from my earlier post still stands and I > think it is the right way to implement something like NT's > WaitForMultipleObjects(). I guess that didn't exist in my 9.0-current that I looked at, so I replied privately with something very similar ;-) With this one could wrap pthread objects, semaphores, etc. The wrapper functions would have to additionally call kevent() to trigger the event if the object was being waited on in a kqueue, as in: typedef struct { #define MY_MTX_IN_KQUEUE 0x0001 int flags; pthread_mutex_t mutex; } my_pthread_mutex_t; my_pthread_mutex_unlock(my_pthread_mutex_t *m) { if (m->flags & MY_MTX_IN_KQUEUE) != 0) { /* Trigger the event. */ kevent(...); } ret = pthread_mutex_unlock(m->mutex); } -- DE From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 17:38:05 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97FF41065670; Thu, 11 Feb 2010 17:38:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 66C3B8FC0A; Thu, 11 Feb 2010 17:38:05 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F269C46B29; Thu, 11 Feb 2010 12:38:04 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 4FE0A8A01F; Thu, 11 Feb 2010 12:38:04 -0500 (EST) From: John Baldwin To: Daniel Eischen Date: Thu, 11 Feb 2010 12:36:31 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <201002110857.12206.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002111236.31975.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 11 Feb 2010 12:38:04 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "threads@freebsd.org" , freebsd-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: Thu, 11 Feb 2010 17:38:05 -0000 On Thursday 11 February 2010 11:49:03 am Daniel Eischen wrote: > On Thu, 11 Feb 2010, John Baldwin wrote: > > > On Wednesday 10 February 2010 7:10:53 pm Daniel Eischen wrote: > >> On Feb 10, 2010, at 3:06 PM, Alfred Perlstein > >> wrote: > >> > >>> * Daniel Eischen [100210 12:01] wrote: > >>>> > >>>> > >>>> I strongly disagree. Using mutexes and condition variables in the > >>>> proper way is not as easy as it sounds, let alone trying to mix > >>>> them as userland thingies into kqueue. > >>>> > >>>> I will strongly oppose this... > >>> > >>> Well then you "win". I have no desire to engage in such discussion. > >>> > >>> I do hope that when you see this facility leveraged elsewhere for > >>> an application that you reflect on this conversation and think back > >>> on it the next time an opportunity presents itself to lead in > >>> functionality. > >> > >> Don't misunderstand me, I just don't think running around the tree and > >> adapting all the userland leaves to kqueue-isize them is the right > >> approach. IMHO, it's better to extend the kqueue/kevent mechanism to > >> allow a generic object to be added to the event list and the kqueue to > >> be signaled from userland. All the pthread and semaphore functions > >> are userland operations that also rely on userland structures anyway. > > > > kqueue/kevent already support that via EVFILT_USER, and Apple's GCD depends on > > this extensively. However, my point from my earlier post still stands and I > > think it is the right way to implement something like NT's > > WaitForMultipleObjects(). > > I guess that didn't exist in my 9.0-current that I looked at, so > I replied privately with something very similar ;-) With this > one could wrap pthread objects, semaphores, etc. The wrapper > functions would have to additionally call kevent() to trigger > the event if the object was being waited on in a kqueue, as in: > > typedef struct { > #define MY_MTX_IN_KQUEUE 0x0001 > int flags; > pthread_mutex_t mutex; > } my_pthread_mutex_t; > > my_pthread_mutex_unlock(my_pthread_mutex_t *m) > { > if (m->flags & MY_MTX_IN_KQUEUE) != 0) { > /* Trigger the event. */ > kevent(...); > } > ret = pthread_mutex_unlock(m->mutex); > } I thought about doing something like this, but I think it is both kludgey and racy. It also doesn't fit in nearly as nicely as in Windows where the standard system objects can be used with WaitForMultipleObjects(). -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Thu Feb 11 17:38:05 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 97FF41065670; Thu, 11 Feb 2010 17:38:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 66C3B8FC0A; Thu, 11 Feb 2010 17:38:05 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F269C46B29; Thu, 11 Feb 2010 12:38:04 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 4FE0A8A01F; Thu, 11 Feb 2010 12:38:04 -0500 (EST) From: John Baldwin To: Daniel Eischen Date: Thu, 11 Feb 2010 12:36:31 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <3581A86D-9C9C-4E08-9AD3-CD550B180CED@lakerest.net> <201002110857.12206.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002111236.31975.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 11 Feb 2010 12:38:04 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "threads@freebsd.org" , freebsd-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: Thu, 11 Feb 2010 17:38:05 -0000 On Thursday 11 February 2010 11:49:03 am Daniel Eischen wrote: > On Thu, 11 Feb 2010, John Baldwin wrote: > > > On Wednesday 10 February 2010 7:10:53 pm Daniel Eischen wrote: > >> On Feb 10, 2010, at 3:06 PM, Alfred Perlstein > >> wrote: > >> > >>> * Daniel Eischen [100210 12:01] wrote: > >>>> > >>>> > >>>> I strongly disagree. Using mutexes and condition variables in the > >>>> proper way is not as easy as it sounds, let alone trying to mix > >>>> them as userland thingies into kqueue. > >>>> > >>>> I will strongly oppose this... > >>> > >>> Well then you "win". I have no desire to engage in such discussion. > >>> > >>> I do hope that when you see this facility leveraged elsewhere for > >>> an application that you reflect on this conversation and think back > >>> on it the next time an opportunity presents itself to lead in > >>> functionality. > >> > >> Don't misunderstand me, I just don't think running around the tree and > >> adapting all the userland leaves to kqueue-isize them is the right > >> approach. IMHO, it's better to extend the kqueue/kevent mechanism to > >> allow a generic object to be added to the event list and the kqueue to > >> be signaled from userland. All the pthread and semaphore functions > >> are userland operations that also rely on userland structures anyway. > > > > kqueue/kevent already support that via EVFILT_USER, and Apple's GCD depends on > > this extensively. However, my point from my earlier post still stands and I > > think it is the right way to implement something like NT's > > WaitForMultipleObjects(). > > I guess that didn't exist in my 9.0-current that I looked at, so > I replied privately with something very similar ;-) With this > one could wrap pthread objects, semaphores, etc. The wrapper > functions would have to additionally call kevent() to trigger > the event if the object was being waited on in a kqueue, as in: > > typedef struct { > #define MY_MTX_IN_KQUEUE 0x0001 > int flags; > pthread_mutex_t mutex; > } my_pthread_mutex_t; > > my_pthread_mutex_unlock(my_pthread_mutex_t *m) > { > if (m->flags & MY_MTX_IN_KQUEUE) != 0) { > /* Trigger the event. */ > kevent(...); > } > ret = pthread_mutex_unlock(m->mutex); > } I thought about doing something like this, but I think it is both kludgey and racy. It also doesn't fit in nearly as nicely as in Windows where the standard system objects can be used with WaitForMultipleObjects(). -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Sat Feb 13 18:20:08 2010 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C175D10656A4 for ; Sat, 13 Feb 2010 18:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 872488FC24 for ; Sat, 13 Feb 2010 18:20:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1DIK8QM037344 for ; Sat, 13 Feb 2010 18:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1DIK8Ss037343; Sat, 13 Feb 2010 18:20:08 GMT (envelope-from gnats) Resent-Date: Sat, 13 Feb 2010 18:20:08 GMT Resent-Message-Id: <201002131820.o1DIK8Ss037343@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, cfxapjwm Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A52E1065693 for ; Sat, 13 Feb 2010 18:16:08 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 22DFC8FC0C for ; Sat, 13 Feb 2010 18:16:08 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o1DIG7T5000349 for ; Sat, 13 Feb 2010 18:16:07 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id o1DIG7uc000348; Sat, 13 Feb 2010 18:16:07 GMT (envelope-from nobody) Message-Id: <201002131816.o1DIG7uc000348@www.freebsd.org> Date: Sat, 13 Feb 2010 18:16:07 GMT From: cfxapjwm To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: threads/143898: cfxapjwm 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: Sat, 13 Feb 2010 18:20:08 -0000 >Number: 143898 >Category: threads >Synopsis: cfxapjwm >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Feb 13 18:20:08 UTC 2010 >Closed-Date: >Last-Modified: >Originator: cfxapjwm >Release: cfxapjwm >Organization: cfxapjwm >Environment: cfxapjwm >Description: zecqsdzy http://uptmtsdo.com sjaunwwr sqvnvxcw >How-To-Repeat: cfxapjwm >Fix: cfxapjwm >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Sat Feb 13 18:24:31 2010 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AE081065784; Sat, 13 Feb 2010 18:24:31 +0000 (UTC) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 345D48FC0A; Sat, 13 Feb 2010 18:24:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1DIOVA1045633; Sat, 13 Feb 2010 18:24:31 GMT (envelope-from deischen@freefall.freebsd.org) Received: (from deischen@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1DIOVUI045629; Sat, 13 Feb 2010 18:24:31 GMT (envelope-from deischen) Date: Sat, 13 Feb 2010 18:24:31 GMT Message-Id: <201002131824.o1DIOVUI045629@freefall.freebsd.org> To: pvtcxqtu@hepclxag.com, deischen@FreeBSD.org, freebsd-threads@FreeBSD.org From: deischen@FreeBSD.org Cc: Subject: Re: threads/143898: cfxapjwm 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: Sat, 13 Feb 2010 18:24:31 -0000 Synopsis: cfxapjwm State-Changed-From-To: open->closed State-Changed-By: deischen State-Changed-When: Sat Feb 13 18:23:53 UTC 2010 State-Changed-Why: GNATS seems to be getting spammed, another garbage PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=143898 From owner-freebsd-threads@FreeBSD.ORG Sat Feb 13 18:50:07 2010 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91A1B1065693 for ; Sat, 13 Feb 2010 18:50:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 709648FC1B for ; Sat, 13 Feb 2010 18:50:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1DIo7Re070341 for ; Sat, 13 Feb 2010 18:50:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1DIo7nP070340; Sat, 13 Feb 2010 18:50:07 GMT (envelope-from gnats) Resent-Date: Sat, 13 Feb 2010 18:50:07 GMT Resent-Message-Id: <201002131850.o1DIo7nP070340@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, raeawzor Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 558F01065694 for ; Sat, 13 Feb 2010 18:41:23 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4DB8FC0A for ; Sat, 13 Feb 2010 18:41:23 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o1DIfNPD022881 for ; Sat, 13 Feb 2010 18:41:23 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id o1DIfMut022875; Sat, 13 Feb 2010 18:41:22 GMT (envelope-from nobody) Message-Id: <201002131841.o1DIfMut022875@www.freebsd.org> Date: Sat, 13 Feb 2010 18:41:22 GMT From: raeawzor To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: threads/143901: raeawzor 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: Sat, 13 Feb 2010 18:50:07 -0000 >Number: 143901 >Category: threads >Synopsis: raeawzor >Confidential: no >Severity: non-critical >Priority: high >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Feb 13 18:50:07 UTC 2010 >Closed-Date: >Last-Modified: >Originator: raeawzor >Release: raeawzor >Organization: raeawzor >Environment: raeawzor >Description: sjfzvacs http://nhtrsiia.com lidkrwop kbkuguxm wphgebhu [URL=http://vwenovyp.com]ugpffkws[/URL] >How-To-Repeat: raeawzor >Fix: raeawzor >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Sat Feb 13 18:54:05 2010 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 508191065672; Sat, 13 Feb 2010 18:54:05 +0000 (UTC) (envelope-from deischen@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 288858FC13; Sat, 13 Feb 2010 18:54:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1DIs5QS078847; Sat, 13 Feb 2010 18:54:05 GMT (envelope-from deischen@freefall.freebsd.org) Received: (from deischen@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1DIs5YZ078843; Sat, 13 Feb 2010 18:54:05 GMT (envelope-from deischen) Date: Sat, 13 Feb 2010 18:54:05 GMT Message-Id: <201002131854.o1DIs5YZ078843@freefall.freebsd.org> To: fahqyouq@krqcdrgc.com, deischen@FreeBSD.org, freebsd-threads@FreeBSD.org From: deischen@FreeBSD.org Cc: Subject: Re: threads/143901: raeawzor 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: Sat, 13 Feb 2010 18:54:05 -0000 Synopsis: raeawzor State-Changed-From-To: open->closed State-Changed-By: deischen State-Changed-When: Sat Feb 13 18:53:32 UTC 2010 State-Changed-Why: Yet more garbage. http://www.freebsd.org/cgi/query-pr.cgi?pr=143901