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

RE: svn commit: r982375 - in /subversion/branches/performance/subversion: include/svn_io.h libsvn_subr/stream.c

From: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 4 Aug 2010 22:36:03 +0200

> -----Original Message-----
> From: hyrum_at_hyrumwright.org [mailto:hyrum_at_hyrumwright.org] On Behalf Of
> Hyrum K. Wright
> Sent: woensdag 4 augustus 2010 21:34
> To: dev_at_subversion.apache.org
> Cc: commits_at_subversion.apache.org
> Subject: Re: svn commit: r982375 - in
> /subversion/branches/performance/subversion: include/svn_io.h
> libsvn_subr/stream.c
>
> On Wed, Aug 4, 2010 at 2:27 PM, <stefan2_at_apache.org> wrote:
> > Author: stefan2
> > Date: Wed Aug  4 19:27:41 2010
> > New Revision: 982375
> >
> > URL: http://svn.apache.org/viewvc?rev=982375&view=rev
> > Log:
> > Introduce a variant of svn_stream_from_aprfile2, that takes cached
> file handles
> > instead of APR file handles.
> >
> > * subversion/include/svn_io.h
> >  (svn_stream_from_aprfile3): declare new API function
>
> Is this intended as a replacement for svn_stream_from_aprfile2()? If
> so, the the later should be deprecated. If not, I would suggest a new
> name, since we generally only have one non-deprecated version of
> svn_fooN() APIs in any given release. It's okay for the separate
> functions to exist, but they shouldn't be related via the naming
> ancestry.

(2nd followup).

If this is just a wrapper for open and close, you can just add your own
wrapper stream over the existing stream (forwarding to the real stream or
reimplementing the apr wrapper if it is performance critical to do that)
without changing the standard stream implementation. This is why we defined
the stream type in the first place.

In that case you can just move it into your own private header in
subversion/include/private/ with the rest of the file handle cache.

        Bert
Received on 2010-08-05 16:22:55 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.