Greg Stein wrote on Fri, 16 Apr 2010 at 10:48 -0400: > On Thu, Apr 15, 2010 at 17:38, <danie...@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 >
