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:
"
* 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.
Later this week, I'm working on creating an implementation of
svn_client_cat2 which doesn't create a temp file, but directly
translates its input into the output stream. To do that, it needs to
stack a translating stream onto the 'out' stream which is passed as a
parameter. The problem here is that I can't do that: svn_client_cat2
doesn't own the 'out' stream, but does own the translated stream. If
it passes the out stream as a parameter to the translated stream, that
will be owned by that stream and hence svn_client_cat2 will have
claimed ownership of that stream.
Here the model falls apart, because svn_client_cat2 needs to flush the
translated stream (currently only possible by calling
svn_stream_close()), but is not allowed to close the out stream...
So, I see several options to resolve this situation:
* Rev all interfaces which take a stream parameter in order to provide
a parameter through which stacked streams can be returned.
* Rev all streams to support both the 'full ownership' and 'reference
only' ownership models
* Create a special stream which breaks the ownership model by intent,
which can be used to interject between any stacked streams and
non-owned streams
* Create an interface by which stacked streams can 'register' with its
dependee, telling it to call its close method instead of its own close
* Introduce an svn_stream_flush model which solves the flushing part
The last option really isn't one, because it has little to do with the
destructors problem.
Ok, so, I need a bit of input here. I think the least hacky way to do
what I want is option 3 (special stream breaking model by design), but
I'm sure open for other options!
bye,
Erik.
Received on Thu Dec 15 21:11:44 2005