Mark Blewett <boost@blewett.nildram.co.uk> writes:
[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.
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?
No, I don't think so. Writing an efficient portable asynchronous (socket/pipe) I/O library which also easily supports user-defined protocol layers, and which ideally also elegantly supports blocking and non-blocking I/O within the framework as well is not an easy task, but it can be done. -- Jeremy Maitin-Shepard