> I noticed that in gnumach/i386/i386/iopb.c, i386_io_port_add is careful > to release all locks while running kalloc() to allocate some memory for > the I/O bitmap, and goes back to retry via goto. > > Is this in general a good strategy? What is the danger that purposedly > is avoided here? Do I need to do a similar thing when locking the > task I/O bitmap in the new code?
You never want to hold a spin lock (simple_lock) for any length of time that is not strictly bounded and small. The easiest way to be sure of the bounds is never to hold a spin lock while calling other code. The danger is that one processor will spin for a long time while the other processor does this more complex processing (e.g. calling kalloc). _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
