On Mon, Mar 15, 2004 at 09:13:34AM -0800, [EMAIL PROTECTED] 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
