#22462 [Opn->Bgs]: session_start() blocks execution of other scripts

ID: 22462 Updated by: sas@php.net Reported By: cmaxwell at themanor dot net -Status: Open +Status: Bogus Bug Type: Session related Operating System: OpenBSD 3.2-stable PHP Version: 4.3.0 New Comment: If you are done with your session in a long running script, you need to close it appropiately using session_write_close(), otherwise you will see exactly this behaviour. Previous Comments: ------------------------------------------------------------------------ [2003-02-28 09:01:37] cmaxwell at themanor dot net 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. ------------------------------------------------------------------------ [2003-02-27 20:37:55] iliaa@php.net 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