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
