global_lock, how does this work?

[rb...@rkbloom.net]

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.

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.

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.

Ryan

Re: global_lock, how does this work?

[Aaron Bannert <aa...@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.)

> 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.

> 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/

-aaron