From: scott (scottw_at_[hidden])
Date: 2004-03-18 21:56:00
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Jeremy
> > [snip: supporting multi-threading implies supporting scalability]
> > IMHO (apart from inter-thread comms) that means support for
> > i/o. For example if boost.sockets only supported blocking
> calls, I would be
> > disappointed, at a minimum i'd expect to be able to write a
> > webserver.
> I agree, supporting asynchronous I/O is, IMO, an absolute requirement
> for a boost socket library.
Hmmmm. Not sure if this interesting to you guys or not. Finished
the "inter-thread comms" and then implemented async I/O on top of
the first. I now have;
template <typename protocol> struct TCP_connect
template <typename protocol> struct TCP_listen
which might be instantiated thus;
machine_address smtp = create< TCP_listen<SMTP> >();
Expressing the whole establishment of endpoints using the
state machine asyn messaging worked out well.
A real nasty with tackling it from the I/O point of view is
that everything can become "I/O event"-centric. And at application
level (where we would like to live) that is a skewed perspective,
e.g. arrival of a TCP block does not equal an application level
Coping with that one nasty seems to consume big chunks of
> > This is where I run into problems... how far should boost
> abstract the
> > underlying system? Yes it would be nice to have a well
> defined, standard, tested
> > common asynchronous i/o library... but is it an abstraction too far?
Yes. Quite difficult to split. As an indication the cleanest piece I
can split off seems to be my message type, i.e. another variant. And
who wants another one of those?!
The rest is intrinsically bound :-(
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk