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

Re: [DESIGN] Stacked resources ownership model?

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-12-15 23:47:42 CET

Erik Huelsmann wrote:
> In a previous mail
> (http://svn.haxx.se/dev/archive-2005-12/0487.shtml), I tried to start
> a discussion about the ownership model we (should) use when stacking
> resources which need a destructor, such as streams (and files). Greg
> Hudson confirmed later in that thread that the current model is the
> one I think is sane too:

(By "current model" you mean "currently proposed", not "currently implemented".)

> "
> * Streams which read from or write to an underlying object own that
> object, i.e. closing the stream closes the underlying object, if
> applicable.
> * The layer (function or data type) which created a stream is
> responsible for closing it, except when the above rule applies.
> * Window handlers are thought of as an odd kind of stream, and passing
> the final NULL window is considered closing the stream.
> "
> The original problem was that a stream_from_aprfile does not close the
> apr file when the stream is closed, but I want to create an interface
> which returns a stream (which is [sometimes] stacked on an apr file -
> but that's an implementation detail). The above model says it's ok to
> do that and expect the apr file to be closed. So far so good.

It seems to me that:

* svn_stream_from_aprfile() is clearly meant to make a stream that reads from
or appends to an already-open file, and therefore it shouldn't close it.
(Greg's second point.)

* If you want a stream that owns a file, the stream constructor should take the
path as a parameter and open the file, and closing the stream should close the
file. Write a stream constructor that does this ("svn_stream_from_file") and
leave both this and _from_aprfile available as alternatives, as both are useful.

* The decision about whether the bottom-most stream owns its file should be
made by the code that creates that stream from the file, and subsequent
functions that play with the stream need not and should not be able to change
that decision.

Isn't that the right solution?

By the way, could you comment on the doc string of svn_stream_from_aprfile()?
It contradicts svn_stream_from_aprfile(), which doesn't own the file, which is
the implementation method for this.

> /** Set @a *out to a generic stream connected to stdout, allocated in
> * @a pool. The stream and its underlying APR handle will be closed
> * when @a pool is cleared or destroyed.
> */
> svn_error_t *svn_stream_for_stdout (svn_stream_t **out, apr_pool_t *pool);

Is that doc string just wrong?

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 15 23:48:48 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.