Erik Huelsmann wrote:
>>* 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?
>
> Ok. I slept on it and decided to use the svn_client_cat2() example to
> illustrate what I *am* talking about.
>
> If you look at svn_client_cat2, you'll find it's passed a stream *out
> parameter. I want to create a svn_subst_stream_translated () which
> forwards its output to the out stream. Translated streams must be
> closed in order to flush the translation buffers.
>
> With the current ownership model, that would be a problem (closing the
> translated stream), because it would also close the out stream.
> Closing the out stream is no-go, however, since we can't start closing
> streams we didn't create.
OK, that's clear, thanks. Here's my revised view of the situation.
Firstly, to address one of Greg's suggestions:
> 2. When you're temporarily stacking a stream on an un-owned resource,
> just don't close the stream. Add an svn_stream_flush() if we have to.
I don't think not closing a stream is an acceptable solution. The stream may
need to write some trailing data (not just pending data that could be flushed)
in order to make its output valid.
Type 1:
In the "stream_from_aprfile" case the stream doesn't own the file (handle) it's
built on. In your example here, the translating stream must not own the stream
it's built on. Similar situations will probably occur for every kind of stream
built on top of an existing stream or other stream-like resource. e.g.:
stream_from(aprfile) # should not close aprfile
stream_from(stream) # should not close stream
stream_from_stdout() # should not close stdout
In these cases we always need the option of non-ownership. There may well
_also_ be cases where we _would_ like a stream to take ownership of the
existing resource on which it is built; perhaps those can be handled by
registering a "clean-up" call-back function. A less generic alternative is to
write a second version of each constructor, that does take ownership; that may
be simpler but may be considered a bit ugly.
Of course there are things like "stringbuf" that are existing stream-like
resources but that don't need any sort of "ownership" because they have no
"close" or "destroy" method. So:
stream_from(stringbuf) # doesn't matter whether we consider this to
# work on the "owned" or "non-owned" model
Type 2:
The second type of stream constructor is that which creates a stream that is
not built on top of an existing stream-like resource, but is connected instead
to some resource that is internally created or opened, e.g.:
/* Create a stream that acts as a FIFO buffer of unlimited size */
fifo_stream() # should own and destroy any temp files it creates
/* Open the specified file for read/write; close it when finished */
stream_from(filename) # (the file handle is the owned resource,
# not the file itself nor its name)
These type-2 streams are not really a special type, they're just following the
normal principle that if they create/open a resource then they should
destroy/close it.
The type of stream built on an existing resource is the type to which the
"ownership model" question applies, and the second type is obvious and needs no
discussion, but that may have been a source of confusion.
So it seems to me that the proposed ownership model:
> * Streams which read from or write to an underlying object own that
> object, i.e. closing the stream closes the underlying object, if
> applicable.
... is not right. Firstly, all streams read/write an underlying object (apart
from a trivial "null" stream); the important distinction is whether that object
was pre-existing, and thus might well be required to continue to exist in a
usable state after the stream has been finished with and closed. Secondly, I
feel that more commonly the stream will be required not to own the existing
resource, but I may be wrong about that.
I couldn't find an example of a stream *needing* to take ownership of an
existing resource. I think you mentioned one...
Again, this is just my current view of the situation. I'm not dictating anything.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 17 00:58:16 2005