FW: [PHP] - REPOST - Flock manual clarification please ;-)

[Jim Winstead]

Matt Friedman <ma...@sprynewmedia.com> wrote:
> In regards to the <snip> above, under what circumstances might you have
> to create a separate lock file? Is this an OS issue? Is it an issue when
> concurrency is high? The manual says "you may have to"; I am looking for
> some clarification as to when exactly you "may have to" follow the
> <snip> advice.

when you do an fopen("file","w"), it truncates the file -- before you
can call flock(). so if one process locks the file, and starts writing
data, a second one could just come along and blow away all or part of
the data even though the first still has it locked. by the time the
second process calls flock() and notices that the first has it locked,
it has already truncated the file.

jim

[Matt Friedman]

From the manual:

<snip>
Note: Because flock() requires a file pointer, you may have to use a
special lock file to protect access to a file that you intend to
truncate by opening it in write mode (with a "w" or "w+" argument to
fopen()).
</snip>

The manual indicates that you "may" need to use "a special lock file" if
you intend to open a file with "w" or "w+". I wrote some code to examine
this. (2 files) Each file locks a file after opening using "w" to do so.
Then, the file is locked using LOCK_EX. Subsequently executed, each file
appears to respect the lock applied by the other file. (Each file waits
for the lock to be released by the other) - So, I don't see this manual
entry applying in this case.

In regards to the <snip> above, under what circumstances might you have
to create a separate lock file? Is this an OS issue? Is it an issue when
concurrency is high? The manual says "you may have to"; I am looking for
some clarification as to when exactly you "may have to" follow the
<snip> advice.

Thanks as always,

Matt Friedman
Web Applications Developer
www.SpryNewMedia.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Matt Friedman]

Ok, that makes sense to me now. I see how you could lose some data.

Do you have any opinions on what a good algorithm might be for getting
locks without the potential for overwriting data? I suppose I could
create a second "lock file" which I would open using "r" - then, wait
for a lock on the lock file and then go on with any processing on the
actual data file. After the processing is done release the lock on the
lock file. Perhaps there are better ways to do this.

What do you think?

Matt Friedman
Web Applications Developer
www.SpryNewMedia.com

jim

--