On 6/27/11 11:01 AM, Arpad Ray wrote:
On Mon, Jun 27, 2011 at 5:00 PM, Arpad Ray<array...@gmail.com> wrote:
On Mon, Jun 27, 2011 at 4:52 AM, Larry Garfield<la...@garfieldtech.com> wrote:
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...
If the database object isn't manually cleaned up (all references to it
are unset) then that will take place in the second stage of the
request shutdown process, whereas the first stage is running the
shutdown functions, so that shouldn't be an issue.
The most common use case for the second argument is where the user
already calls session_write_close() (probably in their own shutdown
function) and doesn't reopen it - it's then useless for us to register
and call our shutdown function.
Regards,
Arpad
Ah, so the order at the end of the request would be:
- Fire normal registered shutdown routines.
- Fire session-close shutdown routine.
- Call destructors on all objects still outstanding.
That seems fine to me.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
