cel@monkey.org (Chuck Lever) writes:
>
> > It's this: when a thread blocks, you wake up another. The other thread
> > was started and blocked especially for this. The other thread then
> > carries on pulling things to do from your event list, until the first,
> > blocked one returns from the kernel. When that happens, someone
> > receives a signal or some other notification, so that one of the threads
> > can stop again.
> >
> > Upon this simple kernel interface can be built automatic allocation
> > and deallocation of threads, and on that, a simple event handling API
> > that always has the appropriate number of threads to do the work.
>
> this is exactly what an interface like mincore() is designed for. the
> application, or an underlying threads library, can use it to avoid page
> faults that would block all the threads running in an address space.
But then you have to check before every access that it is most likely
not swapped out. I think it would be more convenient to get some
queued signal. Unfortunately that requires lots of kernel changes
if you want it in the same thread (no support to handle EINTR returns
from *_user and forcing SA_RESTART could cause races in the user program),
but it would be possible to send it to another thread
(e.g. like Single Unix sigevent SIGEV_THREAD would specify)
That thread would then switch all user space threads that wait
on the blocked kernel thread to another kernel thread.
Doing a mincore() all the time would be too slow I think.
-Andi
-- This is like TV. I don't like TV.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:07 EST