Re: [Boost-users] asio has a very confusing name - should be changed or made asynchronous

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2007-01-03 20:06:21

Hi Marc,

On Fri, 29 Dec 2006 11:15:12 +0100, "Marc Lehmann" <schmorp_at_[hidden]>
said:
> I just saw that asio went into the boost cvs.
> 
> I was interested because asio claims to provide an "asynchronous I/O
> model", which sounds great.
> 
> However, looking at current asio, there is nothing asynchronous, asio
> is completely synchronous by API

Hmmm, maybe we have different ideas about what an asynchronous I/O model
looks like :)

> (and on POSIX platforms):
> 
> * the asio API is synchronous because it requires blocking calls to
>   io_service.run (), making it completely synchronous by API because
>   no I/O is done asynchronously to the program.

The asio API is, not coincidentally, similar in design to the POSIX
async I/O functions, as well as the Extended Sockets API (ES-API) also
defined by the Open Group, and of course overlapped I/O on Windows. For
example:

* Asynchronous operations are initiated using a function call specific
  to the operation being requested:
    asio - basic_stream_socket::async_receive()
    POSIX aio - aio_read()
    ES-API - exs_recv()
    Windows - WSARecv()

* The application must provide the buffer for the operation when calling
  the initiating function, and ensure that it remains valid (and also
  not attempt to access it) until the operation completes.

* A blocking call is used to wait for operations to complete:
    asio - io_service::run()
    POSIX aio - aio_suspend()
    ES-API - exs_qdequeue()
    Windows - GetQueuedCompletionStatus()

The main difference with asio is that, by default, it combines waiting
for the operations to complete with dispatching the associated
completion handler.

> * on POSIX at least it calls select (or poll), which are synchronous
>   by nature (see
>   http://www.opengroup.org/onlinepubs/009695399/functions/select.html,
>   "select - synchronous I/O multiplexing").

Yes, the asio API can be implemented in terms of synchronous I/O
demultiplexers, such as select (or epoll or kqueue). I see this as one
of asio's key strengths, as it enables the API to be implemented
portably.

It is also intended that the API can be implemented in terms of native
asynchronous I/O if available (and if the implementation actually has
decent performance). This is currently the case for asio on Windows.

The asio API is still asynchronous even if it is implemented in terms of
a synchronous demultiplexer. All that the interface "says" is that when
you initiate an asynchronous operation, the "observable behaviour" (i.e.
the data copy to or from kernel space) will occur some time between the
start of the initiating function until immediately before the completion
handler is called. This means the observable behaviour is asynchronous
with respect to the program's flow of control.

> * it seems to work only on non-blocking filehandles on POSIX, either, so
>   file I/O is either not possible or not asynchronous.

Asio doesn't do file I/O at this time (although it is planned for the
future).

> Is it planned to change the API into an asynchronous API and provide
> asynchronous I/O later? If not, I think it might be better to change
> the name into something that reflects the contents ("synchronous I/O
> model sounds a bit boring, how about "network/nonlinear I/O model" or
> even "standard I/O model").
> 
> Otherwise we would end up with a synchronous I/O model called
> "asynchronous", which will likely confuse a lot of people who want a
> real asynchronous I/O model (as provided by POSIX for example).
> 
> Maybe asynchronous was confused with event-based when naming the
> library? Just because I/O is not done linearly anymore does not mean
> its not done in an asynchronous way, though.

Of course, event-based programming and asynchronous I/O are not mutually
exclusive. IMHO the asio API is both asynchronous and event-based in
terms of what it provides to the library user. That asio can be
implemented using synchronous mechanisms doesn't change this.

Cheers,
Chris