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