ID: 22462
User updated by: cmaxwell at themanor dot net
Reported By: cmaxwell at themanor dot net
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: OpenBSD 3.2-stable
PHP Version: 4.3.0
New Comment:
Using the standard "files" session handler.
>From my own digging, the handler is operating "correctly" based on the
assertion that flock() protects against multiple writes.
The problem is that the call to flock() in mod_files.c uses LOCK_EX
exclusively and not (LOCK_EX | LOCK_NB), which causes a deadlock in the
session handler while it waits for flock() to succeed.
The deadlock prevents the second script from executing. In a normal
web environment, this would not be a problem, but when running as CLI
(without script timeouts) this becomes a major problem.
Previous Comments:
------------------------------------------------------------------------
[2003-02-27 20:37:55] [EMAIL PROTECTED]
What session handler are you using?
------------------------------------------------------------------------
[2003-02-27 12:06:37] cmaxwell at themanor dot net
This is a file locking/blocking issue. While avoiding collision on the
session file may be a "feature", the behavior blocking execution and
not returning an error is a bug.
Run the following script from CLI php on two seperate consoles on the
same host.
The first script will execute, start the session and, quite obviously,
not return.
The second script will start, but will never finish the session_start()
command, nor will it timeout, until the first process finishes.
---------
<?php
$sidnum = "fdc69822e43b7d9a1942f8bae9731e18";
session_id($sidnum);
print "STARTING SESSION....";
session_start();
print "STARTED";
while (1) {}
?>
---------
Some ideas for improved behavior:
- accept an optional parameter to session_start() of "$nonblock" that
allows returning FALSE on blocking error. This avoids breaking
web-based scripts that may rely on the TRUE return code.
- new function wrapper session_start_nonblock() that has nonblocking
behavior and/or an error return code.
Both suggestions leave the onus of how to deal with undefined blocking
behavior up to the application.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=22462&edit=1
