Oops! I did not mean to send that reply yet! Carlo Wood wrote:
As a result of this discussion (about threads) so far, it has become clear that we will HAVE to use IO completion routines (the ports seem to demand threads and we try to avoid an API with explicit thread awareness; forcing the user almost to write MT code) - however, I now read about IO completion routines and it turns out to be a proactor pattern interface... We need to see IF we can reasonably combine IO completion routines (ie, WSARecv()) with your API, before going into details of that API.
OK. However, it is my feeling that, regardless of whatever the ultimate limitations of the implementation are, this should have little affect on my general proposed demultiplexor. The demultiplexor I proposed is only a system-level demultiplexor, not a framework for forcing implemented libraries into submission with some arbitrary paradigm. It is up to dependent components to do the actual submission forcing. :-) Perhaps further details on the sort of library I was proposing may show how this is possible. See below. It seems to me you want to design more than just a demultiplexor. It seems you might want a system that is fully capable of managing the main loop of a sophisticated application, something that you could simply plug a socket class into and suddenly have a high-performance web server. It might manage thread pools for you, and implement a framework for the Apache I/O filtering you mentioned, and a ton of other fun things.
Another important source of experience is libACE. Although libACE provides everything we might need, it doesn't 'connect' well to boost; it has a lot of interfaces that are already done in boost but in another way. Also, I think that libACE is doing more than we need and not everything that we might want. If it were
Let us hope that they will not be saying this about whatever demultiplexor Boost comes up with a few years from now. This is excellent, but I think this is more than a demultiplexor, and I think that these extra things can be separated from the demultiplexor itself, and that this separation is a good thing. So I ask again: what is the scope of "Beyond IOStreams"? Exactly what are the goals and problems to be solved in this discussion? I think there might be some value in presenting a more comprehensive example than the sketchy notes I made availible in the OP. I think I will take some time to make availible some code that demonstrates what I have in mind, as perhaps a prototype to be given consideration along with ACE and asio. Unfortunately I can't simply release code from my prior design, as it is based primarily on runtime polymorphism, not templates. In the meantime, I'd like to keep up with the discussion and see where all of this goes. :-) Aaron W. LaFramboise