apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@rkbloom.net
Subject Re: global_lock, how does this work?
Date Mon, 15 Mar 2004 18:51:04 GMT
Quoting Aaron Bannert <aaron@clove.org>:

> On Mon, Mar 15, 2004 at 09:13:34AM -0800, rbb@rkbloom.net wrote:
> > I am trying to port the testgloballock code to the unified framework, and
> I
> > can't make the child process work.  It seems that
> apr_global_lock_child_init
> > only works if the child process was created using apr_fork.  This means
> that the
> > global_lock API can't be used on non-Unix platforms.  This same problem
> seems to
> > apply to proc_mutex as well, but I haven't tested it yet.
> Are you using a NULL filename? A filename is required in order to
> be portable (the underlying mechanism may chose not to use the
> filename though.)

Nope.  I realize that a filename is required for portability.

> > It looks like we should be passing the lock type into _child_init the same
> way
> > it is passed into _create, so that the internal structures can be created
> properly.
> If each lock mechanism were portable, that would be logical, but
> only the APR_LOCK_DEFAULT mechanism is actually portable. The other
> mechanisms probably don't belong in the main create() function(s)
> since they aren't portable and probably assume a fork()ing environment
> under unix. Blah, httpd.

But, even with APR_LOCK_DEFAULT (which is what I am using), this API _can't_ be
used portably.  It segfaults on any Unix platform if you use apr_proc_create,
and that is just plain bogus.

> > Was this API ever tested with apr_proc_create?  If so, does anybody have
> code
> > that does it?  I am tempted to just fix the API and ignore the API changes.
> > This API is broken enough that it _can't_ be used in a portable program
> currently.
> I wrote a module to show global_mutex usage:
> http://www.clove.org/~aaron/examples/mod_shm_counter/

A module doesn't cut it in this case, because that is tied to Apache, and thus
tied to apr_fork on Unix.

At this point, I am actually -0.95 on the apr_global_mutex APIs and the
apr_proc_mutex APIs as they currently exist, because they just are actually
dangerous when used with apr_proc_create.  I just committed a hack to
testglobalmutex.c to make this work, but it is completely bogus to do it this
way.  I had no choice, because otherwise it made the whole test suite die.  The
same hack will be required in testprocmutex when I convert it to use
apr_proc_create instead of apr_fork.


View raw message