Re: Compressed text-base patch

On Mon, Apr 28, 2003 at 04:18:29PM -0700, rbb@rkbloom.net wrote:
>...
> They all do it. The userdata stuff is an aspect of pools, not of the APR
> types themselves.

Actually... I think it might be more precise to say they are an "aspect of
contexts". When we were thinking about a general context, rather than a
pool, the userdata stuff made some sense. Now that we're just talking about
plain old pools... not as much.

And now that we went back to pools, I definitely don't think they make sense
on a per-object-type basis. Very confusing (obviously :-).

>...
> However, if you really want my opinion, the user_data stuff in APR was
> never fully thought out. I added it because Ken Coar suggested it would
> be cool, and it didn't take long to write. I told Greg Stein a long time
> ago that I thought it was a mistake to keep it in, but he said he really
> liked the feature (it was at a booth at ApacheCon London, years ago). I

Whatever I may have said then :-), I'm hoping it was only when we were
talking about contexts. Cuz now... bleck. I'd say they should go. I *do*
think pool userdata makes sense. Just not the object-based stuff.

IMO, pools define various lifetimes and and scoping. There are times when
you want to associate data with that. Not many, so I wouldn't be extremely
disappointed to see the userdata totally disappear.

> will say it again now, the fact that subversion uses the APR user_data
> code is mildly scary to me, because it almost certainly doesn't do what
> you expect it to do.

We make pretty minimal use of them. In fact, there is a usage in libsvn_subr
that seems like it's totally broken... the pool gets cleared, *then* we try
to grab the data. Ooops! :-)

There is another use dealing with some UTF conversion stuff. I'm not too
familiar with that.

> SVN would be much better served to create the hash table itself rather
> than relying on APR userdata, and APR would be much better served by just
> removing the userdata alltogether. It is a couple of bytes per pool that
> are wasted 99% of the time.

*shrug* At least we delay the creation of the userdata hash table. That
means it is really just an overhead of four bytes per pool for most cases.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org