[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r14066 - in trunk/subversion: include libsvn_fs libsvn_fs_base libsvn_fs_fs

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-04-11 20:58:24 CEST

On Mon, 11 Apr 2005, Greg Hudson wrote:

> On Mon, 2005-04-11 at 03:23, Peter N. Lundblad wrote:
> > I think we should protect against multiple calls of this function. Say
> > that we use libA and libB. Both use libsvn_fs and libAInit and libBInit
> > both call svn_fs_initialize. If we add the check for common_pool being
> > non-NULL, we can resolve this situation by calling svn_fs_initialize first
> > with a pool that we control.
>
> Done, although calling svn_fs_initialize from a library seems like a
> mistake. (Better to let the best-effort fallback happen.)
>
Hmmm... Isn't an Apache module a library? Say that two different Apache
modules uses libsvn_fs...

> > This message should be localizable. Applies for all eror messages you
> > introduced.
>
> Done; I think I tracked down all of the error messages I added. (Of
> course, all of those error messages are very unlikely to occur; a
> threading API should really not allow for the failure of mutex
> construction, locking, or unlocking. Presumably APR is just
> accomodating error codes in various platforms' threading APIs, but it's
> still someone's design error in my opinion.)
>
I agree it is probably never shown, but that's an argument against adding
an error message at all. And BTW, errors during mutex creation aren't
unreasonable IMO. They might allocate resources.

Thanks,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 11 20:53:11 2005

This is an archived mail posted to the Subversion Dev mailing list.