Date: 2006-01-31 02:25:48
I've the same problem as Maciej.
You believe that this problem relies on the streambuf implementation - I
think it doesn't.
It doesn't matter if you use a buffered streambuf with flushing it or an
unbuffered streambuf - the archive blocks in basic_text_iprimitive.hpp,
line 80, 'is >> t'.
I don't know what do you mean with 'streambuf implementation needs
enhancement'? The streambuf reads n bytes from the socket or writes n
bytes to the socket as it was requested by its interface.
So it reads n bytes from the socket and writes n bytes to the socket as
it was passed to the stream which uses the socket_streambuf. It doesN#t
make assumptions about the outer context it is used.
In the read action it returns 0 if the peer has closed the socket and no
more data will be available - so you have to return std::char_traits<
char >::eof() in order to indicate the EOF of the stream.
If the socket (blocking mode) is still open and you try to read n bytes
from a socket you will be blocked until n bytes can be read from the
socket (peer has written at least n bytes to the socket).
I could verify that boost::archive blocks because it tries to read more
bytes than available.
The client writes an archive with 29 bytes (printed out from the
streambuf - value was '22 serialization::archive 3 0') to the socket in
On the peer socket the archive tries to read 4096 bytes from the socket
(also printed out from streambuf operation) in one call.
So this must be block because you can only read 29 bytes from the
As you can see this problem is raised by the boost::archive.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk