Re: Thread implementations...

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Fri, 26 Jun 1998 23:41:13 +1000


MOLNAR Ingo writes:
>
> On Fri, 26 Jun 1998, Richard Gooch wrote:
>
> > > 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.
> >
> > OK, fine. Under Linux (and possibly other OSes) that implement aio_*()
> > using threads, it does not scale very well. [...]
>
> the _current_ implementation. There is nothing that says you cannot
> implement aio_*() with a pool of threads and your 'slice up the select
> space into small pieces and make pieces migrate to get better balance'
> concept ...

How do you slice this up in the face of blocking file I/O? Once a
thread starts a read on a regular file, there it sits. I suppose you
could resort to trickery and fstat(2) FDs and if they are sockets, use
poll(2) as the basis for dispatching to a smaller number of
threads. But then you're back to the scheme I'm proposing, in essence,
just with another layer of code (bloat) on top.

> i was just suggesting this, nothing else. Please use an existing interface
> (unless that interface is broken). Especially as the hard work of
> integrating it and getting it to work has already been done ...

That is what I favour: using the existing interface (poll(2) and
pthreads) in a clever way such that it scales with many open
connections. Also that select(2) and poll(2) should be further
optimised (about 3x is what I can deliver). I hope these changes will
provide us with a scalable interface. However, if this doesn't turn
out to be the case, we should then look at alternatives (such as
"readiness event" queues in the kernel), or some alternative
user-space solution that *does scale*.

> your migrating fd scheme does seem to fit well into the aio_*() API at
> first sight. [same is true for the fcntl() driven RT signal stuff]

Yes, but see above. For HTTP servers, a migrating FD scheme for an
event management abstraction may serve better. Also, since various
OSes will implement aio_*() using threads, and assuming they don't do
clever migrating FD tricks for sockets, this will not serve well for
applications which want to be portable (and still retain reasonable
performance).

The fcntl(2) driven RT signal stuff also looks good, except that it's
non-portable.

I want to emphasise this point: I want to provide a scalable, portable
solution. If I can do something that will make a HTTP server run
faster on any UNIX with pthreads, this is far better than just hacking
Linux to boost HTTP performance.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu