we have two problems in the current code when it comes to
    shutting down apache processes:

    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

    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!)


    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.


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]

Reply via email to