[boost] Re: Asynchronicity (long)

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

Hi Edward,

> Edward Diener wrote:
>
> 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.

That is the basic idea I have for a network layer. It creates worker
threads based on the available API's for the platform. Callbacks are
made directly by those threads. Callbacks are boost::function<>
objects. The reason for this approach is performance. To my
knowledge, there is no alternative where many operations and sockets
are in concurrent use.

Given that, for more day-to-day applications, callbacks from other
threads are not the best idea. For example, a simple email client
would not need that kind of optimization and would be far better off
delegating the callbacks back to a single thread. This is where the
general async library comes in.

> Edward Diener wrote:
>
> 1) No one normally uses 1000 sockets. Be real rather
> than hyperbolic if you are trying to make a point.

As others have pointed out, some applications do play in that arena.
In fact, I don't think any others need the free threaded async
approach described above. A single event processing thread is
sufficient, easier to debug and more reliable.

> Edward Diener wrote:
>
> 2) Any good asynchronous I/O library should be able to
> callback on the same thread or another thread.

Agreed. The question is: how does one specify the thread on which to
make the callback? Again, I believe that is the role of the general
async library.

> Edward Diener wrote:
>
> 3) If I am doing socket programming I often do not want
> to hold up my main thread by having callbacks in it.

If your main thread were asynchronous in nature, it may still be
desirable to route calls back to it instead of a thread #2+.

> Edward Diener wrote:
>
> Good. If you are using an asynchronous library, it means
> by its very nature that you want to perform your action
> in another thread, so that your current thread can
> continue.

I guess that I don't see it this way, at least not in the general
case. Sometimes this is the case, but it really depends on how the
current thread works. In a GUI application, it is perfectly
reasonable to deliver async notification on the GUI thread: it will
still remain usable.

> Whether it is blocking waiting on I/O or not is
> irrelevant. That is up to the programmer to know, not the
> library. If it is not blocking the new thread will handle
> it quickly and exit. Worrying about creating threads is
> thinking about performance instead of design. No matter
> what anyone says, design well first and deal with
> performance later.

True enough. <waxing_philosophical>In a good design, one must
understand things at each level of detail or abstraction and find the
equilibrium that best balances the weighted set of requirements for
each level.</waxing_philosophical> All that is just to say that one
must understand the tradeoffs of aesthetically pleasing designs.

>> The network library however knows better and can provide
>> a much more efficient implementation of asynchronous I/O
>> than an asynchronicity library can do.
>
> You are trying to tie a network library to an asynchronous
> library, and so you are confusing two issues.. Decouple
> them instead. An asynchronous library could be modelled
> around the suggestion I made, and your network library
> could decide to use its asynchronous I/O facilities
> depending on what it wants to do.

Boris is correct, but perhaps the wavelengths are just out of sync. A
network library that delegated async behavior to a general mechanism
(say it had a worker thread come up just to make a call to the
blocking send() API) could never be acceptable, because in doing so
it would not be using OS facilities designed for that very purpose.

What can be used from a general async library in an async network
layer is not time generation via threads (for the most part), but
rather event dispatching, queue management and inter-thread
communication.

Best,
Don

                
__________________________________ 
Do you Yahoo!? 
Yahoo! Sports - Sign up for Fantasy Baseball. 
http://baseball.fantasysports.yahoo.com/