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