[boost] Re: Asynchronicity (long)

From: Edward Diener (eddielee_at_[hidden])
Date: 2005-03-31 18:07:20

Please consider the general design of having asynchronous I/O handled by
callbacks in threads. The callbacks can be easily designated by Boost
Function functions and there is already a Boost Thread library for creating
and manipulating threads. I have already worked in such an environment,
albeit with .NET and not the Boost libraries, but I know this general model
works well and is very flexible. How asynchronous I/O is specifically
implemented in this model is up to the programmer(s) who create it, but I do
not see a reason to invent a model which has already been proven to work
well and which can be supported by other libraries which Boost already
incorporates.

Boris wrote:
> 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
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost