Hi Edward,

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.

That is the basic idea I have for a network layer. It creates worker threads based on the available API's for the platform. Callbacks are made directly by those threads. Callbacks are boost::function<> objects. The reason for this approach is performance. To my knowledge, there is no alternative where many operations and sockets are in concurrent use. Given that, for more day-to-day applications, callbacks from other threads are not the best idea. For example, a simple email client would not need that kind of optimization and would be far better off delegating the callbacks back to a single thread. This is where the general async library comes in.

Edward Diener wrote:

1) No one normally uses 1000 sockets. Be real rather than hyperbolic if you are trying to make a point.

As others have pointed out, some applications do play in that arena. In fact, I don't think any others need the free threaded async approach described above. A single event processing thread is sufficient, easier to debug and more reliable.

Edward Diener wrote:

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

Agreed. The question is: how does one specify the thread on which to make the callback? Again, I believe that is the role of the general async library.

Edward Diener wrote:

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

If your main thread were asynchronous in nature, it may still be desirable to route calls back to it instead of a thread #2+.

Edward Diener wrote:

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.

I guess that I don't see it this way, at least not in the general case. Sometimes this is the case, but it really depends on how the current thread works. In a GUI application, it is perfectly reasonable to deliver async notification on the GUI thread: it will still remain usable.

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.

True enough. <waxing_philosophical>In a good design, one must understand things at each level of detail or abstraction and find the equilibrium that best balances the weighted set of requirements for each level.</waxing_philosophical> All that is just to say that one must understand the tradeoffs of aesthetically pleasing designs.

...

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.

Boris is correct, but perhaps the wavelengths are just out of sync. A network library that delegated async behavior to a general mechanism (say it had a worker thread come up just to make a call to the blocking send() API) could never be acceptable, because in doing so it would not be using OS facilities designed for that very purpose. What can be used from a general async library in an async network layer is not time generation via threads (for the most part), but rather event dispatching, queue management and inter-thread communication. Best, Don __________________________________ Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/