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

Re: [PATCH] Client-side support for Cyrus SASL

From: Vlad Georgescu <vgeorgescu_at_gmail.com>
Date: 2006-06-18 00:17:14 CEST

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))?

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?

> 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 :-(

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 18 00:17:53 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.