apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: apr_lock.h lock scope question
Date Fri, 22 Jun 2001 03:43:57 GMT

> I guess what I'm looking for is a lightweight thread syncronization
> API. This maybe stretching the mantra of APR ("implement what you need
> when you need it"), but I'm interested in putting some more design effort
> into the locking facilities that APR provides. Would it be of any use
> at this time to rethink some of the locking APIs? (ie does
> apr_lock_child_init really belong in apr/locks/*/locks.c?)
> The way I see it right now, APR provides one interface to two distinct
> locking features: thread syncronization (aka APR_INTRAPROCESS), and
> process syncronization (APR_CROSS_PROCESS). In my mind these are totally
> different things that seem to have specific uses in the code. Correct
> me if I'm wrong, but I only see APR_CROSS_PROCESS being used in a few
> places, like the call to accept(), and APR_INTRAPROCESS is used everywhere
> else for generic mutex functionality. For the latter, why don't we just
> use/extend POSIX?

If you use APR_INTRAPROCESS, you will get a light-weight thread locking
mechanism.  What more are you looking for.  In reality, for thread
locking, we always end up using pthreads mutex's on Unix.

> - global resource syncronization (Will modules perhaps need true cross-
>   process syncronization, or will the the process-group-only locking that
>   we have now suffice? I suspect module authors will want true cross-process
>   sync as they look for more creative ways to connect their [legacy] apps
>   to apache).
>    -- the weight of these calls will depend partially on platform support.

This is provided using APR_CROSSPROCESS

> - mutexes -- ideally this is just POSIX. Regardless, this is very lightweight.
>   (much more lightweight and well defined than the current one-size-fits-all
>    apr_lock_*() stuff :)

This is what we do.

> - conditionals and rwlocks (these pretty much go together, and would be
>   built upon the mutex routines) -- much more heavy than simple mutexes,
>   but IMHO widely useful throughout httpd and the modules.

Conditionals weren't portable when I looked at them.  Basically, Windows
couldn't do them, but I'm not a windows programmer, and I didn't look at
it too hard.


Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131

View raw message