[boost] Re: 2. It is unavoidable to use threads (was: behond IOStreams)

From: Darryl Green (darryl.green_at_[hidden])
Date: 2004-09-12 23:51:04

Carlo Wood <carlo <at> alinoe.com> writes:

> 
> > 2. It is unavoidable that this library uses threads.

On some platforms, you are almost certainly right - as an
implementation detail. But I don't agree that threading
needs to have anything in particular to do with the IO
multiplexing lib.

> 
> There are two main reasons that I see:
> 
> 1) On windows we have a limitation of at most 64 'Event' objects
>    that can be 'waited' for at a time.  This is not enough
>    for large server applications that might need thousands
>    of TCP/IP sockets.

Ok.

> 
> 2) On windows there are different types of handles/events.  It
>    seems to make a lot more sense to use different threads
>    to wait for different types.  For example, there is a
>    WSAWaitForMultipleObjects (for sockets) and a WaitForMultipleObjects
>    that allows one to wait for arbitrary events (but not socket
>    events(?)).  More in general however - there seems to be
>    a need to use different ways to demultiplex and handle
>    different types - even if the handles of all different types
>    are the same (ie, 'int' on UNIX).

UNIX is a mess given various combinations of SysV IPC, posix, aio
that works for disk and not much else (ymmv) etc with various
extensions and implementation "details". I'm not sure that trying
to support them all is the right direction. Can't we define some
set of waitable objects/interfaces that can be implemented on top
of whatever platform facilities work best (with a fallback/initial
impl that uses whatever works at all on a reasonably basic
platform)? This might do away with the "need" for threads (which
are yet another source for incompatibility anyway) at some cost in
flexibility.

>  Consider the major
>    difference between a listen socket, a very busy UDP socket
>    and a very busy memory mapped filedescriptor.  It might be
>    easier to regular priority issues between the different types
>    by putting their dispatchers in separate threads.

Maybe (probably not for select, but perhaps for kqueue, epoll)?
But why does this need to be reflected in the design beyond allowing
(not requiring) many threads each with its own event dispatcher?

>    Note however that I DO think that the callback functions
>    for each event (that is, the moment we start calling IOstream
>    functions) should happen in the same thread again; this
>    new library should shield the use of threads for the user
>    as much as possible!

You propose that threads may be needed as an impl detail that should
be hidden. I agree - but I don't see how that is any different from
suggesting any other platform dependent implementation detail -  eg.
futex's and epoll should/might be used on linux. Hopefully, the
interface doesn't change. I think you are saying you want an interface
that allows the priority of a waitable object to be specified in some
way, but that they get delivered in priority order to a single thread?
So a minimal approach would be a single event receiver thread waiting
on a non-prioritised system event interface, placing events into a
priority queue for delivery to the "main" thread? That sounds like a
reasonably portable approach, and one that can with little effort
support multiple event receivers to address other issues you raise, but
I don't think it should be visible at all to the user, or required by
the design. I can also imagine cases where the overhead of such an
approach would be excessive, and it would be preferable to use a more
limited dispatcher with less overhead (or to use multiple such
dispatchers, each operating independently, in their own thread, and
leaving any synchronisation issues between these threads up to the user.

Oh - you say it makes no sense to agree with higher numbered issues.
I'm not sure why - this threads issue seems orthogonal to all the rest?
Or are you saying that your impl. of 3+ relies on threads?

Regards
Darryl.