From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-21 04:07:30
--- Peter Petrov <ppetrov_at_[hidden]> wrote:
> My understanding is that the "service repository" is actually
> only needed for the asynchronous operations.
I think there may be some confusion on this point. Even a
hypothetical synchronous-only sockets implementation in asio
would still need the "service repository".
It occurs to me that I have neglected to mention one other
important point about why a demuxer parameter is required,
regardless of whether or not the application is making use of
async operations: portability. On some systems it is necessary
to initialise something before sockets or other I/O objects can
Let's take the specific example of Symbian:
- The Symbian sockets API is based on BSD sockets, but is
presented as a collection of C++ classes (as is the rest of
the Symbian programming interface).
- Before using sockets, an IPC connection to the socket server
(a separate process) must be established. This is achieved by
opening an RSocketServ object.
- A reference to the socket server must be supplied when opening
a socket, i.e.:
TInt RSocket::Open(RSocketServ& aServer, ... other args ...);
- Similarly, a reference to the socket server must be supplied
when opening an RHostResolver object:
TInt RHostResolver::Open(RSocketServ& aServer, ... etc ...);
Even on Windows it is necessary to initialise Winsock using
WSAStartup before socket operations are available. Likewise,
when socket operations are no longer required you need to call
With respect to using singletons as a means to address this,
leaving design objections aside, Symbian does not allow programs
to have global or static data - something I had actually
If the demuxer parameter is not passed to the socket, then
portability to operating systems with these requirements would
So I wonder if the problem is really just one of naming.
Specifically, the name of the demuxer class.
Asio started life as a library intended for asynchronous
use-cases, and for developers with that sort of background I
believe the name demuxer (i.e. demultiplexer) is perfectly
Now that it has grown into general purpose use, perhaps the
name should reflect the expectations of a wider audience.
I propose that it could be called something like "io_system".
(Other naming suggestions will be appreciated.) Consider the
- An io_system object must be initialised before sockets (or
other I/O objects) can be used. See the portability
- An io_system object is an extensible collection of I/O
- Synchronous operations implicitly run the io_system object for
an individual operation.
- You must run() the io_system object for it to perform
asynchronous operations on your behalf.
- You can partition your program by using multiple io_system
For asynchronous operations, the fact that a demultiplexer is
used is an implementation detail. The public interface of asio
does not prohibit an implementation that uses, say, a thread per
Given the portability rationale for requiring such a parameter,
I can't think of any reasons, be they conceptual, ease-of-use or
otherwise, to have a low-level synchronous-only interface.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk