apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@rkbloom.net
Subject Re: testglobalmutex.c
Date Mon, 15 Mar 2004 18:56:29 GMT
Quoting "William A. Rowe, Jr." <wrowe@rowe-clan.net>:

> 
> >rbb         2004/03/15 10:33:30
> >
> >  1.1                  apr/test/globalmutexchild.c
> >...  
> >  int main(int argc, const char * const argv[])
> >  {
> >      apr_pool_t *p;
> >      int i = 0;
> >      apr_global_mutex_t *global_lock;
> >  
> >      apr_initialize();
> >      atexit(apr_terminate);
> >      
> >      apr_pool_create(&p, NULL);
> >      apr_global_mutex_create(&global_lock, LOCKNAME, APR_LOCK_DEFAULT, p);
> >      apr_global_mutex_child_init(&global_lock, LOCKNAME, p);
> 
> Hold on :)  You *created* the lock in the testall.exe process right?
> 
> Now you want a child to use the same mutex - not to create another,
> so the apr_global_mutex_create is redundant and harmful.

Nope.  Take a look at the thread that is complaining about the API for
global_mutex and proc_mutex.  Without that global_mutex_create call, the program
segfaults on any Unix machine.  This is a bug in the _child_init API, because it
should accept a lockmech_e argument so that the lock can be created properly.

The tests work if you use apr_fork, but they die horribly if you use
apr_proc_create.  Since no test code was ever written to exercise this code
using apr_proc_create, this API bug went unnoticed.

I am -0.95 on the current API and very close to veto'ing it.

Ryan

Mime
View raw message