In article <20050614132636.GA22812@antioche.lip6.fr>,
Manuel Bouyer  <bouyer@antioche.lip6.fr> wrote:
> On Tue, Jun 14, 2005 at 02:42:47AM +0000, Jed Davis wrote:
> > Now, the Linux backend handles this by spinning off a kernel thread
> > to do the request-juggling; they don't have to care about blocking
> > allocation in that context, and indeed don't.  I don't know what the
> > NetBSD view on this sort of thing is.
> 
> I'd prefer is we didn't go with a kernel thread for this. kernel thread
> inplies context switching which is not cheap.

Noted.

> I think we can just use
> a callback-based mechanism (much like xm_shm does) around pool_put().
> Would be nice if pool(9) already had support for this :)

I suppose one might argue that pool(9) in fact does, and it's called
ltsleep(9).  But that one isn't me; and anyway, the amount of state that
actually needs saving here is rather less than a whole thread context.
(Which is not to say that state-machine-ifying all this won't be mildly
annoying.)

Oh, speaking of state: is there any reason why the array of machine
addresses for an I/O needs to be kept around until xen_shm_unmap time?
The xen_shm subsystem does keep its own record of that, after all.

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))