[boost] Re: Asynchronicity (long)

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-02 03:01:19

Hi Boris,

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

Sounds good...

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

The answer to a good part of this is a question<g>: since C++ is not
garbage collected, how should we deal with the case when the object
to which "callme" belongs gets deleted while we are waiting for
block() to return? Once "dlgt.BeginInvoke()" in your example is
called, we have a dependency on the target "callme" that must be
managed somehow. This is the purpose of the channel class I proposed.
That being said, I've never created a facility quite like the
example, so I will give it more thought and get back to you.

> Regarding asynchronous I/O: If we had an asynchronicity
> library which could call any blocking function
> asynchronously it would do so by using threads.

Yes, but that is not what I was proposing :) The pseudo code I posted
was focused on the event queue, enqueue, dispatch and cancel. There
was nothing about making time via worker threads. The example you
showed could be changed slightly to queue a call to callme to be
delivered on the same thread that called BeginInvoke (assuming it was
cooperative).

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

True if your original example was the only facility provided by that
library. Other means should be used by the network library to deal
with I/O completion.

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

Indeed.

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

Yes. I agree.

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

Again, making time was not the goal of the technique I was proposing.
It was about the mechanics (of hopefully the "classical" and the
quantum kind<g>) of event queues based on boost::function<>.

> An asynchronicity library should then be tightly
> connected to Boost.Thread - it isn't a stand-alone
> library at all?

The facility you described above could be a convenient wrapper around
inconvenient functions that block. This would be much better than
hand coding such a thing, but would hopefully not be something that
one had to use often. It raises too many issues for the
non-garbage-collected land in which we live (out parameters and what
not).

Best,
Don

                
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/