Re: 2 problems with shutdown

ping? On Thu, Jun 28, 2001 at 05:45:13PM +0200, Thies C. Arntzen wrote: > > 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 >