On 12/15/05, Greg Hudson <ghudson@mit.edu> wrote:
> On Thu, 2005-12-15 at 21:10 +0100, Erik Huelsmann wrote:
> > 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.
>
> I thought about that kind of situation, but decided it shouldn't be a
> problem as long as svn_client_cat2 doesn't close the stacked stream.
> (Although that raises another issue: apr files register pool cleanups to
> close the file, but streams do not do the same thing to close the
> stream. If we ever change that, then it will be impossible to avoid
> closing the stacked stream.)
I'm not sure what you mean by the last sentence.
If we were to introduce a pool cleanup which closes the stream, the
underlying file can't have been closed yet, because a flush to a
closed file will generate an error. This means that the only way to
support stacked resources would be to remove svn_stream_close and
force resource destruction through pool destruction. (I hope the
resources are destroyed LIFO in that case though.)
> One of the options you didn't list was abandoning the ownership model
> for stacked streams and making them all interface-only, like
> svn_stream_from_aprfile is.
Exactly, because it doesn't solve the case where I want to be able to
return a stream which is already stacked on a resource I'm not
returning.
bye,
Erik.
Received on Thu Dec 15 21:56:29 2005