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

Re: Delta-composer && (undefined but required) stream behaviour

From: <kfogel_at_collab.net>
Date: 2005-12-12 04:59:49 CET

Erik Huelsmann <ehuels@gmail.com> writes:
> While writing new streams which I want to use to feed the delta
> composer, I noticed the delta composer expects streams to support
> reads after partial results have been returned. Ofcourse, a read like
> that should return a zero-length block, but nowhere in the stream docs
> is this requirement documented.
> Is it a bug in the window composer, or in the stream documentation?

It sounds like at least a buglet in the window composer.

This documentation in svn_stream.h clearly says that a short read is
okay the first time:

 * The read and write handlers accept length arguments via pointer.
 * On entry to the handler, the pointed-to value should be the amount
 * of data which can be read or the amount of data to write. When the
 * handler returns, the value is reset to the amount of data actually
 * read or written. Handlers are obliged to complete a read or write
 * to the maximum extent possible; thus, a short read with no
 * associated error implies the end of the input stream, and a short
 * write should never occur without an associated error.

But yeah, we don't talk about what happens if you do another read on
the same stream :-)

> (I'm tempted to say it's a bug in the window composer, but that it's
> desirable to have streams support the behaviour even if we fix the
> window composer...)

If we can change ("fix") the window composer to not do this, then why
would we still think it's desirable for streams to support this
behavior? Is there another use case?

This is not a rhetorical question, by the way. If we can think of a
reason why it's useful, I'm all for explicitly documenting that
streams should allow reads after the first short read. But if there's
no use case, I instinctively feel that streams should be strict by


www.collab.net  <>  CollabNet  |  Distributed Development On Demand
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 12 06:25:55 2005

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.