[boost] Re: Asynchronicity (long)

From: Boris (boris_at_[hidden])
Date: 2005-04-01 10:40:07

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

I don't know why a C++ network library shouldn't be able to do what eg. is 
possible in .NET.

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

No problem with that.

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

Yes, there are various possibilities to support asynchronous I/O although 
callbacks seem to be most asynchronous. :)

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

Okay.

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

Considering the bad support of asynchronous I/O on different operating 
systems I disagree that we should ignore the performance impacts of design 
decisions.

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

No, I don't want to do this. It is perfectly okay to have a stand-alone 
asynchronicity library. I am trying to find out if a network library should 
make use of such a stand-alone asynchronicity library or if the network 
library should deal with asynchronous I/O itself.

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

But how does the network library provide asynchronous I/O operations to the 
library user? If you tell me that's up to the network library asynchronous 
I/O provided by the network library will be used differently than what eg. 
an asynchronicity library might provide. And I am only talking about the 
interface not about the implementation. The nice thing in .NET is that 
asynchronous operations look everywhere the same no matter if you are in the 
network library or somewhere else.

Boris