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

[Robert Watson]

On Fri, 9 Apr 2004, Seigo Tanimura wrote:

> (3) Let a dedicated kernel thread call the methods of struct
>     filterops.  
> 
> The headache of kqueue is that KNOTE() ultimately calls back the caller
> subsystem.  Tty would suffer from the same pain as well. 
> 
> Assuming that a kqueue event need not be delivered synchronously upon
> the event, maybe we can attach an event queue to a knote list.  KNOTE()
> appends an event to the queue and wakes up a dedicated kernel thread
> (kqueued).  It then dequeues the event in a queue to call a filter
> *without* the lock of the event source. (socket, tty, etc.) 

Such an approach would be fine by me, but it would also have some
complications.  For example, we need to make sure we handle the case where
a kqueue event thread wakes up to handle a socket event, but the socket
has been free'd.  It's not all that bad, it just involves a necessary
amount of paperwork as well.  It does seem that the fundamental problem
here is that KQueue is one of the more incestuous of support subsystems in
the kernel, and a little bit of redesign might well be called for, because
it will simplify the locking, but probably also clean up other concerns.
The MAC Framework is also an incestuous subsystem, but it does a lot less
"calling back" than KQueue does.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research