apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: testglobalmutex.c
Date Mon, 15 Mar 2004 19:16:33 GMT
At 12:56 PM 3/15/2004, rbb@rkbloom.net wrote:
>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.

No need - we have open season on [re]defining APR 1.0 and this is a beautiful
example of an api that needs to be rethought (we agree :-)

Just add it as a 1.0 showstopper in status...

* the apr_global_mutex_create construct implies creation - and if the
  resource exists (created by another proc) the create call can be
  reasonably expected to fail.

* if apr_global_mutex_child_init is a fork-only behavior (parent-child relation)
  then that should be called out.  If so, a third fn for apr_global_mutex_open
  (detached procs) should exist, or we should have a flag to distinguish
  the initial exclusive create from an open existing flavor of _create.

Make sense?

Bill

* 


Mime
View raw message