Messages in this thread | | | Date | Fri, 26 Jun 1998 23:43:44 +1000 | From | Richard Gooch <> | Subject | Re: Thread implementations... |
| |
Stephen C. Tweedie writes: > 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.
Yep.
> 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.
Yep.
> 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.
Yep.
> 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.
Hopefully completion ports/readiness event queues will not prove necessary, migrating FDs between two threads should do quite well.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |