In message <E1BSlfi-0003ch-00@smeg.dsg.stanford.edu>Jonathan Stone writes

>>(2) When they have fine-grained locking there, they may block 
>>(lockmgr() locks sleep).

Example #1: imagine we have SMP-safe reeentrant network drivers (a la
the patch postd here a few months ago.) Imagine the rest of the kernel
is also fine-grained SMP.

We're darn well *not* going to be using a sleeplock to synchronize
accesses to the per-protocol input queues: the sleep/wakeup penalty is
bigger than the operation being protected.  We'll use spinlocks
instead.  Follow the same logic up the rest of the network-stack.
PF_unix aside, I think the only place you really want to sleep is
between the top of the socket layer and actual process I/O.

Sure, locking (say) multiple TCP hash-tables, to parallelize and
spread hash lookups amongst multiple CPUs, gets hairier.  But I
successfully implemented sendfile() and splice() on OSF1/DU/Tru64,
using a framework very similar to kcont. I dont think it gets any
hairier than that.

Besides, once you get the continuation-passing framework right, most
programmers don't need to mess with it. See opencrypto(9) for one example.