On Thu, 16 Sep 2004 07:49:20 -0400, Hugo Duncan wrote
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.
Ok, at the end of the game it's main use in ACE seems to be for implementing queues for active objects and sending data across threads. Of course it's ugly because it's not typesafe (at least without alot of effort). In a fairly recent project a co-developer wrote his own using a condition variable and std::queue -- he did this instead of using the ACE queues b/c it was cleaner.
Isn't this just one use case?
Well, I suppose there are others but this is the one I run into all the time..
Is a streambuf all you need to be able to support this?
No, I actually need the stream on top of the streambuf so I can do formatted writes/reads to the buffer. Then I need to be able to use the buffer contents to send via the socket -- ideally without copying. BTW, I've done this using std::stringstream before. It was 'horribly inefficient' since I had to bulk copy the streambuf contents to the socket after I was done serializing on write and had to bulk copy to the buffer on read (although I'm not 100% sure I had to copy on read now that I think about it). Anyway, the code was simple and clean and the peformance hit for this app was minimal.
How would you implement a protocol stack?
I'd probably build up a series of serializeable objects that contain other serializeable objects. Or I might have a specialized archiver that knows how to build protocol headers since often times the protocol wrappers need to know nasty little details like the length of the message.
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...
HTTP server sounds like an ambitious example :-) But sure serialize and spirit a huge pieces of the puzzle here.
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.
Yeah, I see. No doubt we are going to need to enhance the streambuf concept to deal with async i/o. I'll have to ponder this a bit if I can ever get my head above water on the email chain, etc... Jeff