Here's another argument in favour of adding a new hook to php_request_shutdown(): the point of session_set_save_handler() is to allow userspace code to implement alternative methods of session storage. Writing to alternate storage will typically involve calling some other PHP module. But how can we safely call other PHP modules when half of them will have had their RSHUTDOWN functions called? There is the potential for subtle bugs dependent on module load order: dangling pointers, memory corruption, etc.

This is a hen and egg problem. First issue which comes to mind is: What happens if a destructor wants to log it's state or such in the session?

We have tuned the order multiple times and the current behaviour is the best of the bad choices we have.

If you add this to your code, it works around the problem, while still closing the session as late as possible I think :

<?php
register_shutdown_function('shutdown_session');
function shutdown_session() {register_shutdown_function('session_write_close');}
?>

@nicolas: Yes, I know, I did it before I reported this bug. I linked to the revision in my internals post. 

http://marc.info/?l=php-internals&m=130025049301140&w=2

@tstarling: read your patch. My code above has one more thing you maybe didn't notice: I call register_shutdown_function twice. First to register shutdown_session, then inside shutdown_session to register session_write_close. This way, I push the session_write_close call after other shutdown registered functions.

So I would change your memsess_write_close function definition at http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83147 with :

 function memsess_write_close() {
-	session_write_close();
+	register_shutdown_function('session_write_close');
 }