RE: [boost] Inactive Objects

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 
> 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