Well, according to my highly technical methods of deduction (fprintf(stderr, "Inside sapi_shutdown");) sapi_shutdown is never called when serving a PHP request when served using mod4_php under Apache. This is because the shutdown_wrapper never gets initialized as a cleanup function. This because the php_init_handler is never called, and this happens for some reason undivinable by me. Perhaps it should be used, and we should execute regular shutdown functions there, and proceed to use php_request_shutdown in the way it was used prior to php 4.1.x i.e. after the connection has closed (on apache anyway) and while PHP is still in memory. We'll get the added benefit of (on Apache systems anyway) a significant performance gain as the cleanup phase happens without the client having to wait for it.
Here is my vision based on my understanding of the inner workings of PHP. There are at least four types of shutdown functions in PHP (not including extensions): PHP space (identified by the use of register_shutdown_function) module_shutdown (called when a module is to clean up after itself) sapi_shutdown (not used under many sapi implementations) php_shutdown there may also be zend and tsrm shutdown functions. php_shutdown seems to always be a call to shutdown wheras the remainder are called when shutdown occurs. Thus the cleanup/shutdown routines should be called in this order: main init load and run PHP script call sapi_shutdown which calls module_shutdown on all used modules and then executes register_shutdown_functions and then calls php_request_shutdown in a server specific manner (in apache as a cleanup_function after the http communication has terminated) which (under platforms that support it) executes register_offline_functions before cleaning up PHP and freeing memory. SAPI was developed for abstracting the server, but it seems that instead it has been worked around rather than extended for the individual servers. I speak in generalizations, but that's what it looks like. In my book, all php internal functions should be called through the appropriate SAPI functions, which are called by a main function for each sapi implementation. There is too much deviation from this, thereby crippling SAPI. Either use it or cut it out completly. These changes are too large for a minor version release, i.e. 4.3.1, but perhaps for 4.4/5.0? I'd be willing to put some time into reworking the SAPI system. > -----Original Message----- > From: Zeev Suraski [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 31, 2002 4:21 AM > To: Joseph Tate > Cc: Php-Dev List; Jason Priebe > Subject: RE: [PATCH]apache_register_shutdown_function final version > > > As you can see in bug #15209, the change that introduced this problem was > that we started calling php_request_shutdown() in apache_module_main(), > prior to calling it from php_apache_request_shutdown(). So, the place to > put it is clearly php_apache_request_shutdown(), where it used to > be called > before. > > The problem is by the time you would get to > php_apache_request_shutdown(), > the per-request memory manager is already deactivated, so any emalloc()'d > memory you may have is already freed. I'm not sure how to tackle > this in a > server independent way... > > Zeev > > At 21:55 30/12/2002, Joseph Tate wrote: > >That's no good. If I remove the sapi_close stuff, and try to execute the > >shutdown functions in php_apache_request_shutdown() all I get is stuff in > >the error log listing the "leaked" memory. The requested > function does not > >get executed. > > > >Joseph > > > > > -----Original Message----- > > > From: Zeev Suraski [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, December 30, 2002 1:57 PM > > > Subject: RE: [PATCH]apache_register_shutdown_function final version > > > > > > > > > Try looking at php_apache_request_shutdown() in mod_php4.c. It's > > > our pool > > > destructor. > > > > > > Zeev > > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php