Hi Michel,
Ok the reason I expose it is for the possibility to write single threaded reactive servers.
I have written such using the library I proposed. The missing ingredient is a function queue mechanism. I posted one to the list a couple weeks ago, but feel that it is not technically a networking thing. Of course, the network layer could be coupled to it in some key places which would make things simpler to use. The downside I see with a single-threaded server is that it can only scale so far (even coded directly to select/epoll), because it can't take advantage of multiple processors. So, in my mind I didn't consider this style one on which to focus great concern for optimal performance. For high performance, IMHO, you need a multi-threaded solution.
Both yes and no. An implementation such as active_event_dispatcher could provide this choice and functionality, at lower layer there should be implementations that let the user of the library make the choices (and even going reactive single threaded). And eg using iocp the threading is basically done by the os (just as long as you have a pool of thread dequeing packages). For the other notification mechanisms i guess a leader follower pattern should be implemented.
I have a hard time seeing why users should care, unless they have grown up in this area and just want to know/control everything. As a library user, I want to focus on my problems. Networking was something I was forced into and have had to make the best of it<g>. I wanted a library that did the right thing, did it efficiently and offered me choices on how I wanted to know when operations were complete. Some choices trade convenience for efficiency. Maybe I am guilty of making this "simpler than possible" to paraphrase Einstein, but I don't think so. I see this like basic_string<>: it will make most of the people happy most of the time. It will never be able to dislodge direct approaches where portability is of little concern and absolutely optimal performance is required. In such efforts, iostreams, FILE* and other standard facilities start being eliminated as well in favor of native API's (i.e., "down to the metal"). I think the times that this will be necessary given my proposal will be very few. No library can reasonably expect to be spared in the quest for optimal performance. ;)
I think ut looks fairly good as well and agree whith calebs and have kind of don't like the extensive use of shared_ptr I think ownership and resource managment should be handed over to the user and not mandated by the library.
I'm not totally in love with shared_ptr either, but it was a more or less direct port from the original. The shared_ptr does bring a good deal of inefficiency with it (though that is improving steadily). If others feel the same, I will look at how to best do without. Best, Don __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail