Greg Stein wrote on Fri, 16 Apr 2010 at 10:48 -0400:
> 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.
>
We have plenty of callback types [e.g., 1,2] that accept both a baton
and a pool. And probably a few that go the other way (e.g., [3,4]).
Do we have a preference these days, one way or the other?
(FWIW, [1] accepts an baton+pool in trunk, but only a baton (with pool,
presumably, in the baton) in 1.6.)
Daniel
[1] svn_sqlite__transaction_callback_t
[2] svn_ra_progress_notify_func_t
[3] svn_cancel_func_t
[4] svn_close_fn_t
> Cheers,
> -g
>
Received on 2010-04-16 17:43:13 CEST