Date: Wed, 14 Jul 2004 13:35:44 -0400 From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h Message-ID: <20040714173544.GU1626@green.homeunix.org> In-Reply-To: <Pine.NEB.3.96L.1040714103934.83353K-100000@fledge.watson.org> References: <200407140702.i6E724mV093920@repoman.freebsd.org> <Pine.NEB.3.96L.1040714103934.83353K-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 14, 2004 at 10:43:23AM -0400, Robert Watson wrote: > > On Wed, 14 Jul 2004, Alfred Perlstein wrote: > > > Log: > > Make FIOASYNC, FIOSETOWN and FIOGETOWN work on kqueues. > > Have you tried testing this on a kqueue used to monitor signals? I'd draw > your particular attention to the following newly enabled code path: > > pgsigio() -> psignal() -> tdsignal() -> do_tdsignal() -> KNOTE() -> > knote() -> KNOTE_ACTIVATE() -> knote_enqueue() -> kqueue_wakeup() -> > pgsigio() > > It strikes me that adding sigio support to kqueue opens a massive can of > worms, not least of which is how you prevent the above from causing the > system to panic, not to mention how you handle locking in what is > otherwise a set of leaf functions in kqueue. I'd like it if you could > back this out until locking for kqueue is resolved, as while this is no > doubt a useful feature, having the locking working is much more useful to > us for 5.3. Agreed. Much of kqueue "barely works" as is (that is, other than pretty much all of it which is broken with regard to concurrency); adding more interfaces, especially this one, is not a good idea (right now?). -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040714173544.GU1626>