httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: APR questions/issues
Date Sun, 02 Jul 2000 15:58:00 GMT
On Sun, 2 Jul 2000, Greg Stein wrote:

> I just ran into a sticking point on the DAV integration dealing with file
> locks. How are locks-per-file done with APR? Specifically, if process A
> opens file Foo, how do we get process B to block when it tries to open the
> same file?
> 
> Both ap_lock_t and ap_file_t seem to assume that the lock/file object is
> shared between the processes to accomplish the locking procedure. I'm
> looking for two independent locks/files/whatever to be created and then to
> interlock.

Two answers here.  :-)

1)  This isn't really a portable operation IMHO.  As such, this should be
done inside an ifdef with native code.

2)  If you are using flock or fcntl ap_lock_t's, then you can open the
file, and call ap_create_lock with the same file name.  Perhaps we need to
make a new ap_lock function that will always use flock or fcntl, but I
really don't know how Windows would implement this.

> I've listed this in the STATUS file, but figured that I'd call it out here.
> APR appears to missing one feature that DAV needs, and one that it would be
> nice to have.
> 
> *) there does not seem to be a chmod() equivalent. the DAV code uses this to
>    set executable flags on files in the repository (e.g. when somebody
>    uploads a CGI script, they can then enable it for execution)

Chmod is definately not portable.  There are people who have implemtned
chmod for Windows, but we don't have it.  I really tried a while ago to
come up with a way to abstract out file permissions, but I never could
figure it out.  There are two answers.  1)  Figure out how to abstract out
file permissions.  2)  Use an ifdef.

> *) the DAV code optimizes a "move" on the same dev_t by just doing a rename.
>    The ap_finfo_t structure exposes the inode, but not the dev_t. This is
>    actually a bit weird, as the inode is specific to the device (in other
>    words, why expose it when it isn't unique by itself). I would like to
>    keep the optimization based on the dev_t. Any issues with exposing that
>    in the finfo structure?

Go ahead and put the dev_t in there.  When I wrote the ap_finfo_t, I only
put in what we needed.  We had one place where we were using the inode,
and none where we were using the device.

Ryan

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


Mime
View raw message