[boost] Re: State of giallo, (sockets and demultiplexing)

From: Hugo Duncan (hugoduncan_at_[hidden])
Date: 2004-09-16 06:49:20

Hi Jeff,

On Wed, 15 Sep 2004 Jeff Garland wrote:

> On Wed, 15 Sep 2004 07:48:15 -0400, Hugo Duncan wrote

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

The Message Block stuff, yes, but not wholesale. Trying to make it easier
to use.

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

Isn't this just one use case?  Is a streambuf all you need to be able to
support this?  How would you implement a protocol stack?

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

using boost.serialize and spirit are two examples that I would like to
build.  I have started an http_server that uses spirit to parse the header,
but early days yet...

>> There is a streambuf implementation, but I have not found a way to
>> implement this without it degenerating to a thread per connection
>> model.
>
> I would think it would tend to be a streambuf per connection regardless  
> of the threading?

What I was trying to say was that I have been unable to implement a  
streambuf
that uses asynchronous IO without having the implementation of the  
streambuf
degenerate to thread per connection.  The only way I could think of
getting asynchronous IO notification to work is to have the streambuf
block on a condition variable after read/write and have that condition
variable notified in the io completion routine. ie, as far as I can
see, the streambuf concept is broken if you do not want a thread
for each connection.

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

I second that.

Hugo