Re: CVS update: subversion/subversion/libsvn_fs rev-table.c

Ben wrote:

> Note that svn_stream_close() does not deallocate the memory
> associated with the stream; destroy the pool you created the
> stream in to do that.

> So in GregH's last sentence, what does "memory associated with the
> stream" mean?

Sorry to be unclear. I meant the memory allocated for the stream
structure itself. I was just trying to say that, per Greg Stein's
discipline, stream structures are not allocated in a subpool. No
memory is allocated by the stream abstraction in the process of
accessing the stream.

> The creator can also set a handler for close requests so it can
> clean up data associated with the baton; if a close handler is
> not specified, a close request on the stream will simply be
> ignored.

> And what does his phrase "data associated with the baton" mean?
> Remember that users calling svn_stream_close() have no idea that any
> kind of stream-baton was created under the hood.

So? That sentence was for the creator's point of view.

> (Of course, why would anyone *want* that kind of control? What use
> would the stream object be if its hidden baton were destroyed? Why
> would you even want the stream object around anymore?)

It's not a question of control. It's a question of not creating
subpools when it's not necessary. We don't create subpools for
svn_string_t objects either, not because we want control but because
it's simpler.

The point of svn_stream_close is not to free memory. It is to say
"I'm done {reading/writing} this stream now," which is important for
things like svndiffs. Our pool management system means that an
explicit destruction method is not necessary for every data type we
have, but for some reason we don't seem to all be on the same page
about that.

I'll clarify the comment.
Received on Sat Oct 21 14:36:25 2006