[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: API docs and pool usage

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-05-07 18:06:49 CEST

On Sat, 2005-05-07 at 13:39 +0200, Branko ╚ibej wrote:
> I'm not Philip, but I suggest we change the docstring to "may be
> allocated in @a pool". We do that in other places where a function may
> return a statically or dynamically allocated object.

I object, based on Peter's dynamic loading scenario. I think returning
a static string is generally a meaningless performance optimization, and
even the most bizarre of borderline cases should be considered a
showstopper bug for a meaningless optimization.

Apart from that, "the return value may be allocated in pool" is too
vague. If it's not allocated in pool, there are a variety of other
options the implementation might use, such as a pool associated with one
of the passed-in objects.

> >Say we have an application plugin (for whatever application you can think
> >of) that uses our libraries. The app load the plugin that links to our
> >libs. The plugin calls an svn functiion that returns a value "allocated in
> >@a pool"; @a pool is controlled by the application. The plugin gives the
> >return value to the app, which it thinks is OK, since the alue is
> >allocated in a pool that the app controls. The app unloads the plugin and
> >then uses the data returned. Crash!

> Well, obvioiusly lifetime is important, and whatever you return must
> have a lifetime that is /at least/ the same as the lifetime of the pool,
> but there's nothing wrong with it being longer (and static strings have
> an "infinite" lifetime).

I think you missed how Peter's scenario makes a static string have a
shorter lifetime than the passed-in pool.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 7 18:07:43 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.