[boost] Re: Asynchronicity (long)

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?

Boris

> [...]