[boost] Re: Asynchronicity (long)

From: Edward Diener (eddielee_at_[hidden])
Date: 2005-04-01 09:14:20

Boris wrote:
> 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.
>
> While asynchronicity in .NET is basically based on threads it is not
> true
> for asynchronous I/O. If you built asynchronous I/O on top of an
> asynchronicity library with callbacks in threads you will end up with
> 1000 threads blocked in read() if you have 1000 sockets.

1) No one normally uses 1000 sockets. Be real rather than hyperbolic if you
are trying to make a point.
2) Any good asynchronous I/O library should be able to callback on the same
thread or another thread.
3) If I am doing socket programming I often do not want to hold up my main
thread by having callbacks in it.

> This doesn't
> happen in .NET and I don't think anyone want this to happen in a C++
> network library. As an asynchronicity library doesn't know if a
> blocking function does I/O it will always call this function in a
> thread.

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

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

> However in
> order not to confuse the application programmer asynchronous
> operations should look
> the same: rules for naming functions that do asynchronous operations,
> basically similar signatures of these functions etc. .NET has these
> rules (see
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconasynchronousdesignpatternoverview.asp)
> and it apparently works well. From this webpage: "The called object
> can choose to explicitly support asynchronous behavior, either
> because it can implement it more efficiently than a general
> architecture ..." In my opinion a socket is such an object which
> should explicitly support asynchronous behavior.

A socket in .NET chooses to operate synchronously or asynchronously. Look at
the .NET socket doc. Similarly your network library can choose synchronous
calls for whatever it does, or it can choose to use an asynchronous I/O
library along my general suggestion.