On Fri, Apr 16, 2010 at 9:48 AM, Greg Stein <gst...@gmail.com> wrote:
> 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. > 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
