2 problems with shutdown

From: Date: Thu, 28 Jun 2001 15:45:13 +0000
Subject: 2 problems with shutdown
Groups: php.dev 
Request: Send a blank email to php-dev+get-58351@lists.php.net to get a copy of this message
hi, we have two problems in the current code when it comes to shutting down apache processes: 1) in main.c php_module_shutdown(): we call php_config_ini_shutdown() before we call the modules MSHUTDOWN functions - which basically means that php is already "half-dead" when MSHUTDOWN is called - so modules can can not rely on certain things (like error_log settings) during MSHUDOWN. is there any known reason not to move php_config_ini_shutdown() further down in php_module_shutdown()? 2) (more serious) if you do an "apachectl restart" the master httpd will signal the worker httpd's. the workers will than call the child_exit hook in all modules no matter where in the code they just happen to be. the problem is that we "try" to clean up the best we can -but- this might cause recursive calls into 3th party library code (which is not supported in most cases!) sample: script calls ociexecute($stmt) (which might take a few seconds) now the admin does "apachectl restart" - and we get interrupted deep down in the oci library. now the worker httpd tries to clean up and calls the child_exit hooks. php will now free all resources and it will also try to do a rollback on $stmt and after that it'll free $stmt. the problem here is that the oracle-server _doesn't_ like recursive calls at all and might crash just 'cause of that. OK - i agree - oracle should fix their code, -but- i don't think its smart to try a real-cleanup if we we're interrunpted during a request. i think we need to protect the engine agains recursive calls. so if child_exit is called while we're still in execution mode simply do nothing (bacause all we could do might be harmful) and leave the clean up to unix. comments? tc

« previous php.dev (#58351) next »