Re: [boost] singleton asio::demuxer as default? (was:asioformalreview begins)

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-12-23 21:31:05

"Christopher Kohlhoff" <chris_at_[hidden]> wrote in message 
news:20051221090730.33683.qmail_at_web32603.mail.mud.yahoo.com...
>
>...
>
> 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
> natural.
>
> Now that it has grown into general purpose use, perhaps the
> name should reflect the expectations of a wider audience.

I think that would be very helpful.

> I propose that it could be called something like "io_system".
> (Other naming suggestions will be appreciated.)

"io_system" seems a little broad. I think of an "io_system" as encompassing 
all I/O mechanisms an operating system supports. A web search turns up broad 
phrases like "The basic model of the UNIX I/O system is a sequence of bytes 
that can be accessed either randomly or sequentially."

"io_engine" implies to me something at a very low level, like the set of 
device drivers.

How about "io_service"? That seems both narrowly focused and about the right 
level to me.

I've changed "io_system" to "io_service" in your text below. Reads quite 
well IMO.

>Consider the
> following statements:
>
> - An io_service object must be initialised before sockets (or
>  other I/O objects) can be used. See the portability
>  requirement above.
>
> - An io_service object is an extensible collection of I/O
>  services (drivers?).
>
> - Synchronous operations implicitly run the io_service object for
>  an individual operation.
>
> - You must run() the io_service object for it to perform
>  asynchronous operations on your behalf.
>
> - You can partition your program by using multiple io_service
>  objects.

--Beman