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 19:30:41 GMT
Quoting "William A. Rowe, Jr." <wrowe@rowe-clan.net>:

> 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?

Yeah, but rather than add a showstopper, I am just going to fix this today.  It
is on my list of things to fix ASAP.

Ryan

Mime
View raw message