On Mon, Apr 28, 2003 at 04:18:29PM -0700, email@example.com 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.
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Apr 29 01:40:10 2003