mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept).

[Brian F. Feldman]

John-Mark Gurney <gurney_j at 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 at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\