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

Re: Streams: EOF detection

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-11-26 21:34:14 CET

Erik Huelsmann wrote:
> On 11/26/05, Erik Huelsmann <ehuels@gmail.com> wrote:
>
>>I'm trying to write a stream implementation and I need to know the
>>criterion for detecting the stream I'm relaying.
>>
>>Now, the headers for streams say that a partially satisfied read
>>(without error) means an EOF condition was found. Reading the
>>implementation for svn_stream_copy, it keeps reading the stream until
>>a non-satisfied read is encountered (returned bytes == 0).
>
> Hmm. Reading the implementation again, I see I'm wrong here.
> svn_stream_copy does it exactly as documented in the headers.
>
>>I think the latter condition is saner, since I think to be told that
>>there are socket reads which are successful, but only return part of
>>the requested data without meaning to signal EOF.

Something odd happened to the grammar of that sentence. Did you mean:

"A socket API exists which has a different interface ... so we should copy what
it does."

Or did you mean:

"Part of our stream API is built on top of a socket API that behaves
differently, and we might not be correctly taking account of the socket EOF
behaviour in the implementation of our stream API, so we might have a bug there
or maybe we've got it right but with a level of complexity that wouldn't be
necessary if we chose matching semantics."

>>What'll be the official 'verdict'?
>
> Well, I guess the question about the strategy remains. Which one is saner?

I don't see anything wrong with the documented method unless the complexity
thing that I mentioned above is a real issue.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 26 21:35:00 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.