Boost logo

Boost :

From: Boris (boris_at_[hidden])
Date: 2005-04-01 17:08:48

Edward Diener wrote:
> [...]
>> But how does the network library provide asynchronous I/O operations
>> to the library user?
> That is up to the network library designer/implementer but I see no
> reason why the network library can not provide both synchronous and
> asynchronous functionality in a number of areas. This is very similar
> to the way that sockets, as an example, works in .NET, where one can
> call certain functionality either synchronously, waiting for the call
> to finish, or asynchronously, returning to do other things while the
> call will finish when a delegate on another thread is invoked.

Maybe I didn't explain myself very good because I also like how .NET
supports asynchronous operations. :) If I take the socket class in .NET as
an example: You could call Socket.Connect() asynchronously like any other
function using a delegate. However the socket class supports asynchronous
I/O explicitly providing a BeginConnect() and EndConnect() method which is
more efficiently implemented. However there is an asynchronous design
pattern in .NET so whoever designed BeginConnect() and EndConnect() had to
follow some rules.

As far as I understand you agree that we should do in C++ similarly? There
should be an asynchronicity library based on threads and callbacks (and
maybe some other features). Then we have a network library supporting
different models of I/O including asynchronous I/O. The asynchronous support
will be explicitly provided by the network library. The library user doesn't
need to use the asynchronicity library himself to do asynchronous I/O as
there will be explicit support just like in .NET. How this explicit support
of asynchronous I/O is implemented doesn't matter.

If we agree upon this we need an asynchronous design pattern in C++, too.
Asynchronous I/O support in a network library must be then designed
according to this pattern. And of course any other library which will
support asynchronous operations explicitly have to follow this design
pattern, too.

>> If you tell me that's up to the network library
>> asynchronous I/O provided by the network library will be used
>> differently than what eg.
>> an asynchronicity library might provide.
> The challenge of an asynchronous I/O library is to provide a general
> enough interface to allow other more specific libraries to use it for
> their own specific asynchronous I/O purposes, else there is little
> purpose in creating it.

Until now I was thinking about an asynchronicity library and a network
library. You think about putting another library in between - an
asynchronous I/O library?


> [...]

Boost list run by bdawes at, gregod at, cpdaniel at, john at