Quoting Aaron Bannert <[EMAIL PROTECTED]>: > 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.)
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. Ryan
