On 06/25/2011 12:13 AM, Arpad Ray wrote:
Hi,
I've updated the patches again.
The most significant change is that the shutdown function registers
another shutdown function when it's called, to (almost) ensure that
it's always the last one, and therefore user shutdown functions should
always find the session available as expected. I'd especially
appreciate feedback or improvements on this because it feels very
hacky. One option is to add a separate hash of internal shutdown
functions which run after the user shutdown functions, another is to
add an element to the module entry, a la RSHUTDOWN, which gets run in
between steps 1 and 2 in the shutdown process (see main.c:1632).
I don't know what other uses there are for this, so I've stuck with
the double shutdown function method in this patch. I'd also like to
avoid complicating the vote on this patch with a tangential issue.
I've added a second optional argument to
session_set_save_handler($obj) which is true by default and indicates
whether the shutdown function should be registered - this is so that
users with their own manual shutdown procedure can disable the
automatic approach. I think that most users will take advantage of the
automatically registered shutdown function, but this lets those with a
custom shutdown procedure handle the session shutdown within the
lifetime of the script and save the slight overhead.
http://spellign.com/patches/php-trunk-session-oo10.patch
http://spellign.com/patches/php-trunk-session-oo10-tests.patch
Regards,
Arpad
I'm a bit confused. If the session handler goes out of its way to
ensure that it's the last thing to run, wouldn't that cause an issue if
it tries to write session data after, say, the database connection
object it wants to use has already been cleaned up? Or is that the use
case for the "do not register" parameter? It seems like it would be a
fairly common use case...
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
