Julian Foad wrote:
> Philip Martin wrote:
>> I still prefer the stream patch I posted earlier, [...]
>>
>> That only allows flushing the stream on close but I do not see any need
>> at present to support flushing at arbitrary positions.
>
> The point about the generic stream API is you should always be able to
> define a new stream class that wraps a stream (examples: a 'tee'
> stream wraps one stream while copying to another; a checksumming
> stream, etc.).
>
> And you should always be able to use the wrapping stream in place of
> the original stream.
>
> The 'svn_stream_flush_to_disk_on_close()' that you suggest breaks that.
>
> The implementation you suggest in your email an hour ago needs direct
> access to the implementation methods of all the stream classes that it
> may possibly encounter (close_handler_gz, for example).
>
> And functionality supported by streams should be provided as a virtual
> method, overridden in each stream class.
>
> Like Evgeny argued in his first email in the thread,
> http://svn.haxx.se/dev/archive-2015-05/0154.shtml
>
> He then proposed a virtualized method 'svn_stream_flush()' which
> solves the abstraction/virtualization issue.
>
> But then you have to define abstract semantics for 'flush', which that
> attempt didn't do well.
>
> It just doesn't all seem to fit together, the idea of telling a
> generic stream "you must ensure the result of this generic stream
> processing is written to *a*/*the*/*which?* phyical disk".
>
> For example, should a 'tee' stream ensure that *both* output streams
> are flushed to disk? That's a rhetorical question: the point is there
> is an semantic mismatch.
Hmm, Perhaps there's not quite as much difference as I was thinking,
between the meaning of "flush this generic stream" and "flush to
disk". It's a matter of how far we push the "flushing" down the chain
from generic stream through to hardware.
If we had a stream method defined as "flush all the way down the
chain, right to the hardware", that would be a meaning that can be
applied to generic streams.
Perhaps the only real problem with the virtual stream_flush method is
that what we actually wanted was "flush on close" not "flush now". The
difference is important in some cases, such as when closing the stream
generates a bit more "trailer" data that gets written after all
incoming data has been processed.
We could of course provide a virtual "stream_close_and_flush" method.
(Either as a separate new method, or with a parameter to the 'close'
method.)
This would be defined as pushing all stream data on through the
system, to the hardware, and to ensure this really happens it would
need to be defined to throw an error if it could not do so.
It might be diffficult to know, in some cases, whether a given stream
implementation is actually able to ensure a flush right through to the
hardware. The underlying library or operating system 'flush' calls
might not be clear about whether that is possible. But we could
probably make a reasonable attempt.
- Julian
Received on 2015-05-28 13:33:48 CEST