Doc #53316 [Opn]: Locks still do not have to be removed manually.

Edit report at http://bugs.php.net/bug.php?id=53316&edit=1 ID: 53316 User updated by: DirectSoft1024 at mail dot ru Reported by: DirectSoft1024 at mail dot ru Summary: Locks still do not have to be removed manually. Status: Open Type: Documentation Problem Package: Documentation problem Operating System: Linux PHP Version: 5.3.3 Block user comment: N Private report: N New Comment: Ok, I forgot about fork() case. What I said is valid only for single-process environment without any duplicate handles. Previous Comments: ------------------------------------------------------------------------ [2011-02-08 16:02:07] an0nym at narod dot ru I've run against this issue as well. Reproduced on Linux 2.6.18-194.32.1.el5xen x86_64 GNU/Linux with PHP 5.3.5 (cli) (built: Jan 22 2011 10:27:18) and FreeBSD 8.1-RELEASE amd64 with PHP 5.3.3 with Suhosin-Patch (cli) (built: Aug 4 2010 07:49:31). I insist this is not a documentation issue. Linux and FreeBSD mans strictly state Locks created by flock() are associated with an open file table entry. This means that duplicate file descriptors (created by, for example, fork(2) or dup(2)) refer to the same lock, and this lock may be modified or released using any of these descriptors. Furthermore, the lock is released either by an explicit LOCK_UN operation on any of these duplicate descriptors, or when all such descriptors have been closed. If a process uses open(2) (or similar) to obtain more than one descriptor for the same file, these descriptors are treated independently by flock(). An attempt to lock the file using one of these file descriptors may be denied by a lock that the calling process has already placed via another descriptor. In other words, if multiple descriptors are open for the same file, flock must not be released until all of them are closed. Moreover, when all of them are closed, flock must be realesed automatically, not manually. How to reproduce <?php $h1 = fopen("test", "c"); var_dump(flock($h1, LOCK_EX | LOCK_NB, $wouldblock1)); var_dump($wouldblock1); $h2 = fopen("test", "c"); var_dump(flock($h2, LOCK_EX | LOCK_NB, $wouldblock2)); var_dump($wouldblock2); var_dump(fclose($h1)); $h3 = fopen("test", "c"); var_dump(flock($h3, LOCK_EX | LOCK_NB, $wouldblock3)); var_dump($wouldblock3); Expected behaviour bool(true) int(0) bool(false) int(1) bool(true) bool(false) int(1) Real behaviour bool(true) int(0) bool(false) int(1) bool(true) bool(true) int(0) ------------------------------------------------------------------------ [2010-11-15 16:22:27] cataphract@php.net Related: bug #51771. ------------------------------------------------------------------------ [2010-11-15 11:57:50] DirectSoft1024 at mail dot ru Description: ------------ Documentation at http://nl2.php.net/manual/en/function.flock.php contains phrase "The automatic unlocking when the file's resource handle is closed was removed. Unlocking now always has to be done manually." Although it no longer calls flock(LOCK_UN) upon encountering fclose(), lock still becomes released by OS when file is closed. So, the phrase "unlocking now always has to be done manually" sounds confusing. Unlocking is still automatic just like it was bore. The only thing that changed is that now it's done not at PHP user side, but inside OS kernel. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/bug.php?id=53316&edit=1