[boost] Re: Re: Asynchronicity (long)

From: Boris (boris_at_[hidden])
Date: 2005-03-31 17:46:06

Scott Woods wrote:
> Hi Boris and Don,
>
> I wonder if my goals are so different that I'm just confusing this
> thread. Unless
> I see something to make me think otherwise I'll leave you with the
> following notes;

Hi Scott, feel free to jump in. :)

> [...]
>> 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));
>
> In your example are you intending that multiple delegates may be
> outstanding on "block" at any one time i.e. several
> "dlgt.BeginInvoke(new AsyncCallback(callme))"
> before the first callback to "callme"?

I brought this as an example as I like the simplicity of asynchronous 
support in .NET and wanted to force Don to explain why he proposes a more 
complicated design. :)  At least it seems to me more complicated (or let's 
say less intuitive) as I could understand asynchronous support in .NET quite 
fast but still have to ask for the exact meaning of Don's nexus and channel 
class.

To answer your question: Yes, in .NET you can call a blocking function 
asynchronously several times by creating different delegates (of course the 
function should be re-entrant). When you call BeginInvoke() you specifiy 
what function should be called back. That can be always the same function or 
a different one. Actually the code above is simplified as there is an object 
passed around which connects the delegate and callback function. In MSDN 
there is an overview about asynchronous programming in .NET: 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpovrasynchronousprogrammingoverview.asp

>> 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?
>
> What thread is performing the callback to "callme"? Ah (answering my
> own question after reading below), any thread from the set of
> "uncountable threads".

Yes, I think "any thread" is the best assumption you can make in .NET. :)

> [...]
>> 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?
>
> Maybe there are three designs lurking here; 1 an interface that
> wraps threads for concurrent execution of blocking functions, 2 an
> interface that wraps queued calls to blocking functions and 3 (long

If I understand correctly in 1) you have n threads for n blocking functions 
and in 2) n threads for m blocking function with n < m? So in 2) you call 
blocking functions one after the other?

> description omitted)
> mine :-)

That was the posting which ended with "Confused?", right? ;)

> Avoiding the issue of which is best (maybe they all have their
> place), what about these points;
>
> * how are parameters passed and results returned
> * what concurrency issues are there (thread safety of parameters and
> globals)
> * does the (async) lib facillitate network messaging (an original
> target)
> * does the lib facillitate async processing of a file or socket
> ("callme" would
> need to carry state info from one call to the next)

All good questions! In this thread I have been trying to understand the 
advantages of Don's proposal by comparing his design with the one in .NET. 
And I have been wondering if it makes sense to build a network library with 
asynchronous support on top of an asynchronicity library as an 
implementation of the network library can not make use then of I/O APIs 
which seem to be much better supported by different operating systems than 
asynchronous APIs. A better solution could be to agree upon some rules about 
how methods (which support asynchronous operations) should be called and 
what their signatures should look like. Eg. in .NET you can always create a 
delegate and call BeginInvoke() to execute a blocking function in a thread. 
But when you have a socket you call BeginAccept() which has a similar 
signature as BeginInvoke(). For the application developer no difference - 
for the library developer the chance to implement BeginAccept() more 
efficiently than with a delegate and BeginInvoke() which would just create 
another thread.

Boris