From owner-cvs-src@FreeBSD.ORG Wed Jul 14 17:35:46 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C2B9616A4CE; Wed, 14 Jul 2004 17:35:45 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i6EHZjpd066846; Wed, 14 Jul 2004 13:35:45 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i6EHZjb4066845; Wed, 14 Jul 2004 13:35:45 -0400 (EDT) (envelope-from green) Date: Wed, 14 Jul 2004 13:35:44 -0400 From: Brian Fundakowski Feldman To: Robert Watson Message-ID: <20040714173544.GU1626@green.homeunix.org> References: <200407140702.i6E724mV093920@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: cvs-src@FreeBSD.org cc: Alfred Perlstein cc: cvs-all@FreeBSD.org cc: src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2004 17:35:46 -0000 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. \,,,,,,,,,,,,,,,,,,,,,,\