Re: [boost] Aaron's Informal Proposal for a Universal Demultiplexor for Boost

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-09-14 19:20:02

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