Quoting [EMAIL PROTECTED]: > 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.
Oh, and this is why I am so against having any non-portable tests in a test suite for a portable run-time. If the test can't be run portably, then the code isn't portable. That doesn't mean you can't do things like use #ifdefs to dictate options like the lock type. But all functions should be run on all machines (within reason. For example, when testing a feature that doesn't exist on a platform, that test won't be run. But when testing a feature that does exist on a platform, the test must be written to work everywhere). Ryan
