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