From: Robert Ramey (ramey_at_[hidden])
Date: 2006-01-31 11:51:46
Actually this does reveal the true issue - and one that can and should
be addressed from withing the serialization library.
text archives output each value preceeded with a space to
separate the tokens. The space is used to delimit the data value.
the last is >> t is waiting for a space to return - it doesn't find it
untl the next archive.
So text archives should be terminated with a space or newline
to prevent this from happening.
I will add this to the text_oarchive destructor. This should
address the problem.
Good work gentlemen,
Maciej Sobczak wrote:
> Robert Ramey wrote:
>>> I have experimented a bit with this program and I've found that when
>>> the sender (the server in this case) flushes the stream, it's enough
>>> for the data to arrive at the destination, and it can be retrieved
>>> by regular stream read (the data is then identical as if the same
>>> archive was written to cout in the first place). But when the
>>> text_iarchive object is used to read it, it blocks. The only way to
>>> make it continue is to close the stream on the server side. So it
>>> looks like the text_iarchive is really waiting for eof (or for
>>> something else in the stream).
>> It may look that way, but that's not what's happening. I recomend
>> you investigate the management (or lack there of, flushing of the
>> underlying stream.
> OK, after further investigation it appears that the archive reader is
> in fact sensitive to one of these two:
> - end of line
> - end of stream
> It is possible to reuse long-lived connection for sending many
> archives (and receiving them without unnecessary waits), provided one
> of these two happens. So, the sender might look like this:
> ?ostream outstream(...);
> while (...)
> boost::archive::text_oarchive ar(outstream);
> ar << myObject;
> // this:
> outstream << std::endl; // or '\n' followed by .flush()
> With this additional newline+flush the receiver has no problems with
> de-serializing the data as soon as they arrive.
> Thank you for helping solving this.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk