On 6/17/06, Vlad Georgescu <vgeorgescu@gmail.com> wrote:
> On 6/16/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> > 2) This doesn't seem to do anything with regard to thread safety.
> > Looking at the cyrus sasl headers there seems to be a sasl_set_mutex
> > function that we're going to need to call. Since they've given us a
> > somewhat bone-headed design to work with, it probably means we're
> > going to have to jump through a few hoops to make it work with APR.
> > I'm envisioning something along the lines of a global pool that we
> > allocate mutexes out of or something like that, with our free function
> > returning the mutexes to a free list or something...
>
> I'm no expert on multithreading, but if we did use a free list as you
> described, wouldn't we have to serialize access to it? How do we do
> that? Wouldn't it be simpler in this case to create a new pool for
> each mutex (with svn_create_pool(NULL))?
Well, you could do that, but you need to keep in mind that each pool
involves a non-trivial amount of memory allocation. There's about 8k
of overhead for each pool, so if all you're going to do is allocate a
single mutex, a pool may be overkill. That said, it depends how many
mutexes SASL will try and allocate, if it only creates a single global
mutex, then so what, if it creates tons of them, then it's something
you need to worry about.
> Also, how do we make sure that sasl_{client,server}_init() is only
> called once? I dug up this thread from the archives:
>
> http://svn.haxx.se/dev/archive-2003-05/2224.shtml
>
> Is there a solution for this?
Well, it really depends on how correct we want to be. We can't be
100% correct, since we can't rely on users of the Subversion libraries
calling an initialize function, since we didn't have one in Subversion
1.0, and thus we can't introduce that requirement now. We can add a
new initialization function and request that people call it, but we
still need to work even if it wasn't called. Perhaps making the
current sasl init function you've got public, but inserting extra
calls to it in ra_svn before we make use of sasl code, just in case...
For other examples of this sort of thing, see svn_utf_initialize,
although that's not really the same thing, since without it we still
work, we just work more slowly. Also svn_fs_initialize().
> > If we don't call sasl_set_mutex what is the behavior? Does sasl use
> > its own internal mutex allocation code? Or does it just not lock?
>
> It doesn't lock :-(
Well, then we really need to worry about it ;-)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 19 17:04:28 2006