[PHP-DEV] 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: 2 problems with shutdown
On Fri, Jun 29, 2001 at 03:23:03PM +0300, Zeev Suraski wrote: At 15:18 29/6/2001, Thies C. Arntzen wrote: agreed - but we should do it, right? Yup :) in the error_log - and sometimes it'll even SEGFAULT. is this good? Is this a trick question? :) Of course it's bad. Perhaps we should revert to only freeing registered resources on a child_exit (module_shutdown, I guess). We can live without actually freeing malloc'd memory, as indeed, it will be auto-freed upon exit anyway. sorry for bashing this;-) i'm sure i'll be able to crash it using any 3th party module. because the restart signal can hit us any time. does anybody know how other apache-modules handle this situation? tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: 2 problems with shutdown
At 18:45 28/6/2001, 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()? The problem is that (if I remember correctly) the INI mechanism may call callbacks in modules that have already been unloaded. It can probably be fixed, but would require some time to play with. 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. I don't know if that qualifies as a recursive call - it's really doing what it's supposed to do. Perhaps the Oracle module should protect itself, but not running cleanup is wrong IMHO - consider semaphores or the likes which won't clean up automatically. Or SQL servers that won't immediately detect that their client is gone. I think that cleaning up is generally an important thing. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
