Boost logo

Boost :

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,


> 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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at