apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: svn commit: r368769 - /apr/apr/trunk/include/apr_file_io.h
Date Fri, 13 Jan 2006 18:35:41 GMT
On 1/13/06, Mladen Turk <mturk@apache.org> wrote:
> Garrett Rooney wrote:
> >>
> >>URL: http://svn.apache.org/viewcvs?rev=368769&view=rev
> >>Log:
> >>Mark pool param for apr_file_remove and apr_file_rename
> >>as unused (because it is).
> >>Perhaps some day it will be removed from the API.
> >
> > I'm not sure how I feel about this.  The pool could potentially be
> > used for temporary allocation some day, if we port to a platform that
> > happens to require it.  Encouraging people to just pass random things
> > in place of the pool argument seems like a bad idea.
> >
> Right, make sense in that case.
> There are also few other functions that have pool
> as a param but never use it like
> apr_env_delete or apr_dir_remove.
> The question is if they'll be ever used, or particularly,
> can someone write the implementation without using pool.
> Since the return value from those functions is int, I'm
> almost sure they could be, by using stack for temp storage,
> and further more since no additional object is created that would
> require cleanup.
> I think they were simply over engineered initially.

Sure, they can use stack space right up until they need to allocate
some memory that's dynamically sized, or call some other APR function
that needs a pool, or...  You see what I mean here.  The end result is
that when you take into account the fact that virtually any nontrivial
function in an APR application requires a pool anyway, we might as
well play it safe and design all but the most trivial APIs (and I
consider anything that isn't a totally in-memory operation on data
that's passed in to be non-trivial) so that they actually have access
to a pool.  You simply cannot predict the requirements of all
platforms, and it's better to have code written today work on those
platforms in the future when the cost (passing a pool) is trivial when
you consider that virtually all APIs in APR require it anyway.

We've actually had this sort of thing happen in Subversion, building
APIs that don't take pools and getting burned eventually by having to
create totally new APIs that do have them in order to accomplish what
was necessary.  It's just easier to have the pool from the beginning.


View raw message