lkml.org 
[lkml]   [1998]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.533 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site