From: Jeff Garland (jeff_at_[hidden])
Date: 2004-09-15 18:14:58
On Wed, 15 Sep 2004 07:48:15 -0400, Hugo Duncan wrote
> Spend a few days off line and you suddenly miss a whole conversation
> :-( It's going to take a while to catch up...
Well, I've been involved and I still not caught up...
> Recent IOstreams discussion has indeed been very interesting,
> espescially as I am finally getting round to implementing buffers
> and filters for giallo (boost.sockets). At the moment I am leaning
> towards ACE style message buffer, using the apache filter idea
> of flush/eos/eoc control (but trying to avoid any knowledge of
> the underlying resource).
Are you talking about the ACE Message Block / ACE Message Queue stuff?
If so, I'm really hoping we can do better. I understand that the key desire
here is to avoid lots of copying and I agree with that. But, honestly I think
at the socket boundary layer we really just want an IOStream that I can
read/write to and control the send/recv. The reason is that typically I want
/ need to make one transformation at the process boundary anyway.
So, for example, when I recieve an inbound message I'm going to unserialize
whatever it is into a native structure. So I have to allocate (or take from a
pool) and go field by field thru the data anyway realizing it into the native
structure. Then I process the data. I'll never make any copies in the
processing core b/c I'm going to pass around shared_ptr's or something.
Going outbound I've built up a complex structure that needs to be serialized
into a buffer that gets sent after I'm done. I'm passing this all around
using smart pointers until I get to the socket stream and it's ready to go
So if I'm writing some network code, I'm thinkin I just want to use
boost.serialize to do the serialization and it needs a stream to do that. And
actually, I'm curious if the file descriptor wrapper in the IOStream library
wouldn't pretty much take care of it?
The only exception I can think of is if the data is to be 'multicast' down 2
> So where is giallo today (apart from being temporarily broken on gcc
> due to mpl changes)?
>...snip lots of good status info...
> There is a streambuf implementation, but I have not found a way to
> implement this without it degenerating to a thread per connection
I would think it would tend to be a streambuf per connection regardless of the
Anyway, glad you're back -- I hope between all the interested parties we can
get enough momentum to sustain things to the point of actually producing a
boost library for demultipexing and sockets....
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk