2 problems with shutdown
| From: | Thies C. Arntzen | 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