Bert Huijben wrote:
[Repeating the first mail then... Thanks tele2 for breaking my e-mail for
the second time this week :(]
-----Original Message-----
From: stef...@apache.org [mailto:stef...@apache.org]
Sent: woensdag 4 augustus 2010 22:22
To: comm...@subversion.apache.org
Subject: svn commit: r982391 - in
/subversion/branches/performance/subversion: include/svn_io.h
libsvn_subr/stream.c
Modified: subversion/branches/performance/subversion/include/svn_io.h
URL:
http://svn.apache.org/viewvc/subversion/branches/performance/subversion
/include/svn_io.h?rev=982391&r1=982390&r2=982391&view=diff
=======================================================================
=======
--- subversion/branches/performance/subversion/include/svn_io.h
(original)
+++ subversion/branches/performance/subversion/include/svn_io.h Wed Aug
4 20:22:10 2010
@@ -926,23 +926,6 @@ svn_stream_from_aprfile2(apr_file_t *fil
/* "forward-declare" svn_file_handle_cache__handle_t */
struct svn_file_handle_cache__handle_t;
If ^^^ this is a library private type (implied by the __).
<snip>
+/** Create a stream from a cached file handle. For convenience, if @a
file
+ * is @c NULL, an empty stream created by svn_stream_empty() is
returned.
+ *
+ * This function should normally be called with @a disown set to
FALSE,
+ * in which case closing the stream will also return the file handle
to
+ * the respective cache object.
+ *
+ * If @a disown is TRUE, the stream will disown the file handle,
meaning
+ * that svn_stream_close() will not close the cached file handle.
+ *
+ * @since New in 1.7.
+ */
+svn_stream_t *
+svn_stream_from_cached_file_handle
+ (struct svn_file_handle_cache__handle_t *file,
+ svn_boolean_t disown,
+ apr_pool_t *pool);
+
/** Create a stream for reading from a range of an APR file.
* The stream cannot be written to.
*
Then this shouldn't be a public function, using that type.
This function should then be moved to the cached file handle prefix and also
use __ in its name.
I don't think this API will have general use outside FSFS in 1.7? (But I can
be mistaken)
Probably not.
If not it should certainly be in a private header, to allow updating its api
later without all our versioning rules for public APIs.
r983385 is the best I could come up with. It avoids code duplication
as well as a performance hit. However, it breaks the nice 1:1 relation
between source and header.
-- Stefan^2.
