On Fri, Apr 16, 2010 at 9:48 AM, Greg Stein <gstein_at_gmail.com> wrote:
> On Thu, Apr 15, 2010 at 17:38, <danielsh_at_apache.org> wrote:
> > Author: danielsh
> > Date: Thu Apr 15 21:38:14 2010
> > New Revision: 934599
> >
> > URL: http://svn.apache.org/viewvc?rev=934599&view=rev
> > Log:
> > Update the svn_atomic__init_once() interface to take a baton, and update
> all
> > callers. The new caller (that needs the baton) will be added shortly.
> >
> > * subversion/include/private/svn_atomic.h,
> > subversion/libsvn_subr/atomic.c:
> > (svn_atomic__init_once):
> > Add a BATON parameter to be passed to INIT_FUNC, and update
> INIT_FUNC's
> > signature to accept it.
> >
> > * subversion/libsvn_fs_base/bdb/env.c
> > subversion/libsvn_ra_neon/session.c,
> > subversion/libsvn_ra_serf/win32_auth_sspi.c,
> > subversion/libsvn_ra_svn/cyrus_auth.c,
> > subversion/libsvn_subr/io.c,
> > subversion/libsvn_subr/sqlite.c,
> > subversion/libsvn_subr/win32_xlate.c,
> > subversion/svnserve/cyrus_auth.c:
> > Update svn_atomic__init_once() calls and callbacks to pass/accept a
> baton.
>
> The pool parameter seems redundant now. Should a function require a
> pool, it can just pass it as the baton, or within the baton.
>
Are you saying that *any* function which takes a baton should not require a
pool parameter? This doesn't jive when my interpretation. We should still
provide a scratch pool for these types of functions, with all that such a
pool implies. If the caller needs a permanent pool, then that pool goes
into the baton.
-Hyrum
Received on 2010-04-16 18:12:18 CEST