Boris wrote:
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.
In .NET, asychronous calls have their own general interface. When the programmer uses, as an example, a socket he/she may choose to call a number of functions either synchronously or asynchronously, with the asynchronous calls using the same general interface as the rest of asynchronous calls in .NET. In the same way if Boost has an asynchronous I/O library built around threads and callbacks, a separate Boost network library should offer both synchronous or asynchronous functionality to the end-programmer. In offering asynchronous functionality the network library can use the asynchronous I/O library to make asynchronous calls. The good thing about this decoupling is that another completely different Boost library, for example a file I/O libary, should be able to use the general purpose asynchronous I/O library for its own purposes also. I am only arguing generally for an asynchronous I/O library built around what already exists in Boost from Boost threads and Boost function ( for callbacks ).
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?
That is up to the network library designer/implementer but I see no reason why the network library can not provide both synchronous and asynchronous functionality in a number of areas. This is very similar to the way that sockets, as an example, works in .NET, where one can call certain functionality either synchronously, waiting for the call to finish, or asynchronously, returning to do other things while the call will finish when a delegate on another thread is invoked.
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.
The challenge of an asynchronous I/O library is to provide a general enough interface to allow other more specific libraries to use it for their own specific asynchronous I/O purposes, else there is little purpose in creating it.
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.
I agree, looking very much the same but allowing both the end-programmer, and the particularly implementation of asynchronous callback functionality, to pass different data to an asynchronous callback, and also using the results of data picked up by the callback in different ways depending on the implementation. I think we are mostly agreeing. My original appeal is that building a general purpose asynchronous I/O library around Boost threads and Boost function seems feasible, since the equivalent concepts have already been shown to work in another environment, and might save a great deal of trouble from trying to re-invent the code from scratch all over again. On top of that general purpose asynchronous I/O library other implementors which need asynchronous I/O in their particular libraries can build whatever elaborate schemes they want. Perhaps "asynchronous I/O" is a bad name and one should just settle for an "asynchronous calls" library, although the I/O portion of it may incorporate general ideas of how to do I/O, perhaps using streams ala the I/O streams library but with the idea that a particular streaming operation may block waiting for input or output to complete. So the breakdown of the problem, from a network library point of view, could be: 1) A general purpose asynchronous callback library. 2) A general purpose asynchronous I/O library using 1) and considering how I/O should be implemented. 3) A network library, or any other library which might want to make asynchronous I/O calls, using 2). Usually when a problem is complex it is much easier breaking it down into manageable pieces, and makes for more resuable programming. That is why Boost is so great, since it offers many great pieces which one can use to build even more complicated things.