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

Re: svn commit: r1233566 - in /subversion/trunk/subversion: include/svn_io.h libsvn_subr/stream.c

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 20 Jan 2012 01:42:42 -0500

On Jan 19, 2012 11:02 PM, "Daniel Shahaf" <danielsh_at_elego.de> wrote:
>
> Hyrum K Wright wrote on Thu, Jan 19, 2012 at 21:47:51 -0600:
> > On Thu, Jan 19, 2012 at 8:40 PM, Daniel Shahaf <danielsh_at_elego.de>
wrote:
> > > I do wonder if the "to disk" threshold should be in the public
> > > signature, but don't have offhand a use-case justifying that.
> >
> > We could, but I figured callers who needed finer-grain control over
> > the size of the buffer would use the underlying private API which
> > gives them that ability. And as I noted in the code, the choice of
> > 100k was completely arbitrary, the result of a lot of squinting and
> > hand waving. If somebody has better guestimates (Stefan F.?) as to
> > what would be better, feel free to improve upon it.
>
> FWIW, my point was that the caller (of this now-public API) may be able
> to have a better guesstimate as they'd know the use-case, the number of
> concurrent spillbuf objects, the typical length (`wc -c`) of the stream,
> etc.

Right. We always assume "caller knows best", and we try to document our
APIs to give them the needed info.

I would recommend exposure, with two DEFAULT constants. I'd be -0 with
making them 0 and documenting their remapping to "suitable defaults". (ie.
allowing callers to use 0 instead of a 20-char symbol)

I'm also a bit concerned with putting these in the public API. I guess our
prevalence of streams kind of demands this "memory shortcut", but I worry
about doing this earlier rather than later. Maybe delay one release? (I'm
confident in the code; unclear on what we want to sign up for long-term)

Cheers,
-g
Received on 2012-01-20 07:43:42 CET

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