Date: Thu, 15 Apr 2004 16:36:30 -0400 From: "Brian F. Feldman" <green@freebsd.org> To: Robert Watson <rwatson@freebsd.org>, Seigo Tanimura <tanimura@tanimura.dyndns.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept). Message-ID: <200404152036.i3FKaUd5018165@green.homeunix.org> In-Reply-To: Message from John-Mark Gurney <gurney_j@efn.org> of "Fri, 09 Apr 2004 11:01:06 PDT." <20040409180106.GM567@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney <gurney_j@efn.org> 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. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404152036.i3FKaUd5018165>