Hi Marc, On Fri, 29 Dec 2006 11:15:12 +0100, "Marc Lehmann" <schmorp@schmorp.de> 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