> 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 _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
