Messages in this thread | | | Date | Fri, 26 Jun 1998 09:59:01 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: Thread implementations... |
| |
Hi,
On Fri, 26 Jun 1998 06:26:17 +0200 (MET DST), MOLNAR Ingo <mingo@valerie.inf.elte.hu> said:
> On Fri, 26 Jun 1998, Richard Gooch wrote:
>> > this is already implemented in glibc 2.1. Take a look at the aio_ >> > interface there. Async threads take care of waiting for IO and stuff. >> >> Yes, you can handle multiple connections using aio_*(), but you end up >> with one thread (with the glibc 2 implementation) per open connection, >> right? So when we have 10000 connections, we have 10000 threads, >> right? I don't think aio_*() scales very well.
> it might be that the implementation does not scale well. Unless there is > something fundamentally broken about the aio_...() interface (API) itself, > why reimplement the wheel? It's a standard interface.
There are two very separate issues here.
One issue is dealing with asynchronous IO requests which have already been submitted. These are typically reads or writes from either disk devices or sockets known to be ready for read. Such requests are expected to be short lived, so we can use aio for them and expect reasonable scalability; even with 10000 fds, we are unlikely to have that many actual IOs in progress at once.
The completion port mechanism answers an entirely different problem. Given 10000 open sockets, how do we tell which ones have valid data on them? On a WAN, we can expect a lot of delays on many sockets, so a typical web proxy may well have very many open sockets but much, much less active readable data at any point in time.
Simply doing 10,000 asynchronous read()s and waiting for them to finish is not, I think, going to be a scalable answer to this problem. Having a completion port mechanism to identify incoming data avoids this. Using aio to actually read the data is another matter; we can do that quite happily and still expect reasonable scalability, because we don't have to queue arbitrarily large amounts of concurrent IO in that case.
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |