The human doc server strikes again. :-)
Thanks, Greg!
Greg Stein <gstein@lyra.org> writes:
> On Wed, Dec 13, 2000 at 12:13:47PM -0600, Ben Collins-Sussman wrote:
> >
> > Greg S. --
> >
> > Do the routines in apr_lock.h work?
>
> Absolutely. Apache would fall over mighty fast if they didn't :-)
>
> > I have a global hash the contains all loaded RA-libraries. I want the
> > structure global, so that multiple threads and processes can share the
> > vtables.
>
> Threads can share. Processes can't.
>
> > However, I want to keep things threadsafe. When a thread
> > needs to load a new RA library, I want to lock down the hash first.
> >
> > However, I have to admit, I've never used muteces. Looking at apr's
> > interface, it looks like I need to
> >
> > * create a lock
> > * associate data with it
> > * lock the lock
> > * edit the data
> > * unlock the lock
> >
> > Is this right?
>
> Create a global mutex (as a sibling of your hash). Initialize the mutex once
> at startup (which will presumably be threadsafe at that point; maybe a
> svn_client_init() function that users must call). Use the APR_INTRAPROCESS
> lock scope to just lock threads out of the access to the hash.
>
> The lock type (mutex vs readwrite) is apparently ignored. Forget that
> parameter. fname appears to allow NULL, so the "always" in the comment is
> bogus(*); you can pass NULL.
>
> [ yes, it looks like I'll be going in there and revamping that API :-) ]
>
> When anybody wants to read *or* write the hash, you must surround the access
> with apr_lock() and apr_unlock().
>
> Cheers,
> -g
>
> (*) Actually, only Unix allows a NULL parameter; all other platforms expect
> one. You should probably just pass one that resides in SVN/tmp/.
>
> --
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006