apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@rkbloom.net
Subject Re: global_lock, how does this work?
Date Mon, 15 Mar 2004 18:53:48 GMT
Quoting rbb@rkbloom.net:

> Quoting Aaron Bannert <aaron@clove.org>:
> 
> > On Mon, Mar 15, 2004 at 09:13:34AM -0800, rbb@rkbloom.net 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

Mime
View raw message