Re: [boost] Serialization and disctintion between eof and end of archive

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-01-30 21:44:51

Maciej Sobczak wrote:
> Hi,
>
> Robert Ramey wrote:
>
>>> The boost.serialization library seems to use eod-of-stream in the
>>> underlying istream object to denote the end-of-archive.
>>
>> Why does it seem that way? It would certainly be contray to my
>> intention.
>
> It seems that way, because this is how it's shown by the example
> program provided by Seweryn on the "users" list:
>
> http://lists.boost.org/boost-users/2006/01/16646.php

That example shows something entirely different.  It does not show
that the serialization code relies on eol to denote end of archive. A
cursory examination of the library source also should convince
anyone that serialization does not depend on end of stream in
anyway.

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

>
>
>> I don't see that this would be a problem.  What is the matter with
>> the following?
>>
>> ?ostream os("pipename or whatever");
>>
>> // first archive
>> {
>>     ?_oarchive oa(os);
>>     oa << ...;
>> } // archive is destroyed here - stream remains open and available
>> // second archive
>> {
>>     ?_oarchive oa(os);
>>     oa << ...;
>> } // archive is destroyed here - stream remains open and available
>>
>> os.close();
>
> The matter is that there might be hours of pause between these two
> blocks above and the receiver might not want to wait that long.

If that's the case, then the ?ostream streambuf implementation needs
enhancement.  It is outside the scope of the serialization library.

The
> archive (the first one) should be succesfully read on the other end of
> the wire as soon as the bytes make their way to the receiver.
> It does not seem to be the case.

It may not be - but it is not something that can be fixed from
within the serialization library.

>> I don't believe the conclusion follows.  The archive has to be
>> constructed and destroyed - but the stream doesn't have to be.

> Yes, but what about the reading part? Is it possible for the reader to
> successfully read the first archive *before* the next archive arrives
> (which can happen hours later)?

This would depend on the streambuf implementation used by the
underlying stream.  The serialization library library requests
all characters required - no more no less.

\
> I hope to be mistaken, but my initial experiments with the OP's code
> led me to the above considerations.

I think you are mistaken.

Robert Ramey

>
> Regards,