dionisos@tigris.org writes:
> Added:
> trunk/notes/destruction-of-stacked-resources
>
> Log:
> * notes/destruction-of-stacked-resources: Add conclusion from dev thread.
Maybe this should go in www/hacking.html, instead of in notes/?
-Karl
> Added: trunk/notes/destruction-of-stacked-resources
> Url: http://svn.collab.net/viewcvs/svn/trunk/notes/destruction-of-stacked-resources?rev=17816
> ==============================================================================
> --- (empty file)
> +++ trunk/notes/destruction-of-stacked-resources Fri Dec 16 17:35:44 2005
> @@ -0,0 +1,56 @@
> +
> + -*- text -*-
> +
> +Some resources need destruction to ensure correct functioning of the
> +application. Such resources include files, especially since open
> +files cannot be deleted on Windows.
> +
> +When writing an API which creates and returns a stream, in the
> +background this stream may be stacked on a file or other stream. To
> +ensure correct destruction of the resources the stream is built upon,
> +it must correctly call the destructors of the stream(s) it is built
> +upon (owns).
> +
> +At first in http://svn.haxx.se/dev/archive-2005-12/0487.shtml
> +and later in http://svn.haxx.se/dev/archive-2005-12/0633.shtml this
> +was discussed in more general terms for files, streams, editors and
> +window handlers.
> +
> +As Greg Hudson put it:
> +
> +==============
> +On consideration, here is where I would like us to be:
> +
> + * 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.
> +
> +If you think of apply_textdelta as creating a window handler, then I
> +don't think we're too far off. svn_stream_from_aprfile isn't owning its
> +subsidiary file, svn_txdelta_apply is erroneously taking responsibility
> +for closing the window stream it is passed, and there may be some other
> +deviations.
> +==============
> +
> +
> +There is one exception to the rules above though. When a stream is passed
> +to a function as an argument (for example: the 'out' parameter of
> +svn_client_cat2()), that routine can't call the streams destructor, since
> +it did not create that resource.
> +
> +If svn_client_cat2 creates a stream, it must also call the destructor
> +for that stream. By the above model, that stream will call the destructor
> +for the 'out' parameter. This is however wrong, because the responsibility
> +to destruct the 'out' parameter lies elsewhere.
> +
> +To solve this problem, at least in the stream case, svn_stream_disown()
> +has been introduced. This function wraps a stream, making sure it's *not*
> +destroyed, even though any streams stacked upon it may try to do so.
> +
> +
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: svn-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: svn-help@subversion.tigris.org
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 19 18:31:55 2005