-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Jeremy
[snip: supporting multi-threading implies supporting scalability]
IMHO (apart from inter-thread comms) that means support for asynchronous 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 "commercial" 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 message. Coping with that one nasty seems to consume big chunks of everything :-)
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 :-( Cheers, Scott