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/htm...
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