[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: <kfogel_at_collab.net>
Date: 2005-11-26 20:16:10 CET

Erik Huelsmann <ehuels@gmail.com> writes:
> 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.
> >
> > What'll be the official 'verdict'?
> Well, I guess the question about the strategy remains. Which one is saner?

Need more context to answer, I think. Is this a new stream
implementation for Subversion, or a usage of Subversion's streams... ?
(If not, we should probably take it off-list.)

I think Subversion's strategy is sane, for a high-level stream
implementation that fits over a lower-level network layer or something
similar. If I were implementing a socket API in a kernel, I might
make it give back a bit more information about what happened on a
short read, though :-).


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 Sat Nov 26 21:38:36 2005

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