Re: [boost] Re: Asynchronicity (long)

From: Scott Woods (scottw_at_[hidden])
Date: 2005-03-31 16:27:56

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;

----- Original Message -----
From: "Boris" <boris_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, April 01, 2005 7:43 AM
Subject: [boost] Re: Asynchronicity (long)

[snip]

> 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));
>

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"?

> 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".

>
> 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?
>

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 description
omitted)
mine :-)

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)

Cheers.