apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apr STATUS
Date Sat, 16 Dec 2000 15:17:18 GMT

> > >   Modified:    .        STATUS
> > >   +    * apr_create_lock() changes:
> > ...
> > >   +      - The fname param is allowed to be NULL on the Unix platform.
> > 
> > feature, not bug...  Do you mean that the semantics associated with
> > this ("make up a file for me if you need to, APR") are not implemented
> > across all platforms?
> > Do you disagree with the usefulness of that feature?
> Not at all. However, I'd rather see *no* parameter, and the code just always
> builds its own filename; or I'd rather see the parameter *always* required
> (because if it can't properly construct the file for some reason, then we
> better always give it the right one).
> IOW, if the function knows how to create a filename that will work for the
> lock (e.g. avoid NFS issues), then why the heck should we pass a value? If
> it *doesn't* know enough, then we better always pass it, or some goofball
> that doesn't pass the value is going to get screwed in some edge case.

APR can not create the filename itself.  And we don't want to
anyway.  Tell me how APR would handle the LockFile directive in an Apache
config file.  It can't unless Apache passes that filename into the

> > >   +        Change it to always use the passed value, and check
> > >   callers.
> > 
> > It uses the passed value when appropriate, right?  Note that we don't
> > always need a file as not all supported lock mechanisms are
> > file-based.
> It uses it when passed, but see above.

It should use it when needed, and return an error if it is needed and


Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131

View raw message