[boost] Re: Asynchronicity (long)

From: Boris (boris_at_[hidden])
Date: 2005-03-31 14:43:47

Don G wrote:
> [...]
>> So the difference between your approach and I/O completion
>> ports in Windows is ... hm, I think in Windows a completion
>> port is a combination of your nexus and channel, isn't it?
>
> It is basically that, yes. The channel class, however, I believe to
> be a very important concept. Merging it with the nexus class would
> create dangerous situations where one would have to ask at the point
> a message is enqueued: "will it be OK to deliver this message
> regardless of what might happen between now and the time of
> delivery?" The key impulse that can make this answer always NO is
> "delete foo". The delete operation is synchronous. Without a channel
> to serve as a way to cancel pending messages to that object, we would
> have dangling pointers in the queue (a bad thing).

Hi Don,

maybe we should go through an example - then I hopefully understand better. 
:)

Let's say we have a function void block(). We call this function and we 
don't know when it will return. Now we want to use an asynchronicity library 
to call this function asynchronously. If we had a library similar to how 
.NET supports asynchronicity code would basically look like this:

AsyncDelegate dlgt = new AsyncDelegate(block);
dlgt.BeginInvoke(new AsyncCallback(callme));

There is a magic class AsyncDelegate which calls block() in a thread. When 
block() returns in the thread callme() is executed which is our callback 
function. If we forget about the class AsyncCallback for a moment I think 
the asynchronous support in .NET is pretty simple and easy to understand. 
How would you call block() asynchronously with your nexus and channel class? 
What is the difference? And what is the advantage of your design which 
introduces two classes whose meaning is difficult to grasp in the beginning?

Regarding asynchronous I/O: If we had an asynchronicity library which could 
call any blocking function asynchronously it would do so by using threads. 
However if the asynchronicity library knew that a function blocks because of 
I/O it maybe would use a better implementation like overlapped I/O. This 
could be a reason *not* to build a network library upon a general purpose 
asynchronicity library. In Linux eg. it might be better to use the new 
epoll() function (new in Linux 2.6) to simulate asynchronous I/O instead of 
creating, managing and blocking in uncountable threads. In .NET the socket 
class has a method BeginAccept(). While there is no difference for the 
application programmer between this method and calling any other method 
asynchronously the .NET framework knows that BeginAccept() does I/O and will 
not create a new thread but do overlapped I/O instead. A network library 
with support of asynchronous I/O must then not be built upon a C++ 
asynchronicity library but must provide the same "look and feel" to an 
application programmer - asynchronicity looks everywhere the same but might 
be implemented differently in the network library for a better performance.

Last but not least after thinking so much about asynchronicity: Isn't an 
asynchronicity library not just another interface for Boost.Thread? Instead 
of managing threads yourself you just tell the library to call a function in 
a thread and then call back. An asynchronicity library should then be 
tightly connected to Boost.Thread - it isn't a stand-alone library at all?

Boris