On Tue, 1 Feb 2000, Jamie Lokier wrote:
> Blocking on disk I/O is a different matter -- there you have
> difficulties because there's no async interface.
...
> You can deliberatly spawn real threads for the blockable things --
> Netscape and Squid do it for DNS lookup -- but that defeats the point of
> an event loop, especially when you don't know which things will block.
> Paging is a cause of inefficiency here: you can't tell when a memory
> access will block. Reading from a file is the other main cause.
>
> For 100% efficiency, you need to always be ready to handle something,
> never an idle CPU. Even paging from disk shouldn't stop your program
> from doing other things.
...
> 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.
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- 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