[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r985514 - stream_move_mark()

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 18 Aug 2010 12:24:23 +0200

On Tue, Aug 17, 2010 at 11:57:11PM +0200, Stefan Fuhrmann wrote:
> I overgeneralized my use-case here: I actually needed "move forward" only.
> The concept of "skip N bytes", however, is perfectly in line with
> the general
> stream semantics. Because this also fits my needs, I changed the API in
> r986485 accordingly.

But the stream implementation may still need to read all bytes until N
anyway, to make sure the internal state is still valid after moving to
offset N.

Of course, we could say that a stream implementation is free to optimize
for this use case if possible, but allow wrapper streams to override
the "move forward" implementation.

For instance, a stream wrapping an APR file would support "move forward",
but as soon as you wrap this APR file stream with a translation stream,
the translation stream's semantics take over and the APR file stream
will effectively be read byte-per-byte when the "move forward" method
is called on the translation stream. This would allow the translation stream
to keep its internal state intact during a "move forward" operation.

Performance benefits would then depend on the type of stream being used.

Does this make sense?

> The problem is that a lot of parser code would need to change at least its
> function signatures to string buffers and offsets instead of
> streams. I'm not
> even sure that all streams are based on strings; some may be parsed on
> APR file as well and use the same parser code (e.g. read hash from stream).

Sure, that's what I meant. The patch code for instance uses multiple streams
all mapped onto a subset of a file, and each such stream does special
filtering and transformations on the text read from the file.
See the definition of svn_hunk_t in include/svn_diff.h.

Received on 2010-08-18 12:25:24 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.