From owner-freebsd-arch@FreeBSD.ORG Thu Apr 15 13:36:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A2C7F16A4CE; Thu, 15 Apr 2004 13:36:31 -0700 (PDT) Received: from localhost (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i3FKaUd5018165; Thu, 15 Apr 2004 16:36:31 -0400 (EDT) (envelope-from green@green.homeunix.org) Message-Id: <200404152036.i3FKaUd5018165@green.homeunix.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Robert Watson , Seigo Tanimura , Pawel Jakub Dawidek , freebsd-arch@freebsd.org In-Reply-To: Message from John-Mark Gurney of "Fri, 09 Apr 2004 11:01:06 PDT." <20040409180106.GM567@funkthat.com> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Apr 2004 16:36:30 -0400 Sender: green@green.homeunix.org Subject: Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 20:36:32 -0000 John-Mark Gurney wrote: > How does this sound to people? I have some code starting to implement > this, but I haven't gotten very far with it yet... You know, now I think Seigo's right on the money that due to the nature of the recursion of kqueue's current implementation, it's impossible to get right with this train of thought. So, let's redesign: * The kqueue object the user controls needs a mutex. * The lists (selinfo, mostly) that knotes are on need locking. * The filterops that kqueue calls out MUST be called with some kind of locking on the lists that the kqueue is on, and the user MUST be able to grab any kind of lock from inside a filterop. * At some point the object being observed must call back into kqueue to add itself. We'll end up getting deadlocks if the locks kqueue holds are not the ones required to add the object to klists and held when we do the f_attach(). * Anything that calls KNOTE() or KNOTE_ACTIVATE() directly will end up recursing back on itself if we don't convert it to putting the new event on a work queue. How filt_procattach() calls KNOTE_ACTIVATE() or filt_proc() calls kqueue_register() is a very good example. * The functions that need to be exported are: * KNOTE()/KNOTE_ACTIVATE() <- put on a workqueue * kqueue_register() <- put on a workqueue * knote klist/(kn_selnext) linking and unlinking * knote klist/(kn_selnext) is disappearing The last two are the only ones that are not called recursively and should have easy locking semantics. Nothing is currently designed to work with anything even remotely not looking like spl(), so we have to either flatten it out (using workqueues) or change semantics so that when KNOTE() is called it acts like the closure that we pretend it is. Of course, the easy way to do this is with a worker queue/condvar/mutex/thread. What other ways do we have available to turn KNOTE() into a closure, bearing in mind that the entire point of the mechanism is that there is no memory allocation at the time of event generation -- only when events are defined (by the user or recursively by other events). -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\