Can't be critical, no one else reported this yet.

Please test with latest Apache/PHP and see if this problem still exists (regardless of the source in sapi_apache.c)

IIRC, somebody from the PHP team set the "Critical" flag after confirming its existence.  I've come to the conclusion that register_shutdown_function() is one of the least-exercised portions of the PHP core, based on the fact that the docs and online comments have never mentioned the fact that it never worked under anything but Apache+*nix.

Seems to me that the nature of the bug _is_ critical, since any application that depends on register_shutdown_function() will fail horribly if the call does not work.

At any rate, we will test.  Thanks.

This bug still exists in 4.2.1 version.  If it's reproduced 6/6 times on different platforms with an average score of 4.9, it's pretty important if not critical.

Here's a sample script:
<?PHP
function foo () 
{
  sleep (10);
  print "foo<BR>\n";
}

print "pre shutdown<BR>\n";
register_shutdown_function (foo);
print "shutting down<BR>\n";

?>

This should return immediately printing
pre shutdown
shutting down

but instead waits ten seconds then prints
pre shutdown
shutting down
foo

This should be discussed.  Generally, it's not obvious that shutdown functions should be executed after the connection shuts down.  It may very well be used to print out information, which obviously cannot be done if it's done after the user disconnects.

I believe that getting this behavior to work is only possible under Apache.  With most (all?) other server APIs, it's only possible to do things while the user is still connected.  So, if we want consistency across web server, the existing behavior is the desired one.

Then we need two functions.  One for the case where we don't want to close the connection, and one for offline processing after closing the connection.  Is there some other mechanism for offline processing?  If not do you have any ideas on how one might implement such an extension?

> Generally, it's not obvious that shutdown
>functions should be executed after the connection shuts
>down.
It's not obvius, but worked (and documented?) this way 
before, and some programs used this feature exstensively 
(such as ours) And now we have to say to our customers 
that they shouldn't upgrade from 4.0.6 if they want to use 
our system. I think there are other people who have the 
same situation.

I agree that there should be a function that can run things after the script has finished with it's output portion. I can think of many examples where this is desirable.

For example, if I wanted to get a list of ads to display on a website, i could run the DB queries that do the logging after the user is happily on thier way to other things. This would yeild a significant *PERCEIVED* speed increase for the user.

If it only works on Apache/*NIX, I think that's fine. More incentive to switch to this platform. There are other functions and features that are specific to this platform too.

I JUST found this function, and I've got a few very good uses for it (the case where the connection is closed BEFORE the function runs). Plus maintaining backwards compatability would be nice :)

I am using AIX 4.3.3, Apache 1.3.26, mod_perl 1.26 and PHP 4.2.2 This problem is one of 2 that are causing compilation failures for me.

The other is that the LARGE_FILE definition (in mod_perl's ap_config_auto.h) is causing "conflicting type" errors for mmap64 when compiling sapi_apache.c (I will raise a seperate bug report for this second problem)

Dup of #14251

Is this really a dupe of 14251?  Maybe they involve some of the same code, but these are really two different issues.  14251 involves the fact that the shutdown function code gets a different working directory.  15209 concerns whether the shutdown function runs before or after the HTTP connection is closed.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

I grabbed a snapshot today (php4-200210040300).  I jtate's script, and still got the erroneous (IMO) behavior.  My connection to the server did not close until the shutdown function completed.  

Looking at the suspect section of sapi_apache.c, I do not see any changes.  Not that I expected to see my patch verbatim, but I would expect something in that vicinity to change.

Marking as critical since this worked at some point.
And there was also posting by jtate@php.net with a possible
fix on php-dev@lists.php.net

Changing to 'Verified', since there is some disagreement on how this function should operate.

I copy my mail sent to the dev list here too, to make it more noticable:

I know there was some hot discussion about this topic but I really need to
get
this bug fixed. Even I'll make a patch with my zero knowledge of c if no one
would like to make it, but please try to find a reasonable sollution that
fits (almost) everyone's need.

I thought of one. I think a new function with the name
register_apache_shutdown_function (or somethink like this) might be good.
It's name would say that it only works in apache, it could be documented
that
it's the *only* function that closes the connection before the registered
functions are handled. Or maybe a parameter could tell if the connection
should be closed before the first registered function is started.

I'll hope there's some way to solve this problem, because it's not easy to
tell every customer to use our patch (or use 4.0.6) before they are staring
to use our programs that rely on this forgotten feature.
Thanks,
Arpi

I gave up on my patch.  Too much work, not enought time, and ultimately, I couldn't find a place in PHP land where PHP was still running and Apache had closed the connection to put my hooks in.  There may be a way to tell Apache to close the connection through SAPI, but I am not aware of it.  (I'm not an apache hacker).  Someone posted a way to fork a process to the background, but it isn't a PHP land solution.

From Carsten Gehling:
Maybe this is what you need?

http://www.naken.cc/mikehup.php

I use this on a CMS site, where the users upload imagefiles with ftp. After
that, they use a php webinterface to start an importscript (written in
Perl). By doing this command in php:

system("/usr/local/bin/mikehup /usr/bin/perl
/www/servers/netlag/cronscripts/import_billede.pl &");

The importscript is started and executes in the background while the
php-script finishes execution.

Hope that helps

- Carsten

The following script will cause IE to stop loading the page when zlib.output_compression is used.  This was not true before the changes to register_shutdown_function as the output was not sent.

You can see a test at http://dealnews.com/zlibshutdown.php.  Mozilla gracefully handles the mixed output by truncating the non-compressed data.

================================
<?php

register_shutdown_function("shutdown_test");

?>

<html>
<head>
<title></title>
</head>
<body bgcolor="#ffffff" leftmargin="8" topmargin="8" marginheight="8" marginwidth="8">
This is in the HTML body.

<?php

function shutdown_test()
{
    echo "This is the shutdown function.";
}

?>

</body>
</html>

I created a patch to add this functionality back under mod_php4 systems.  This patch was posted to the php-dev list yesterday.  Check out the list archives.  An improved patch will be posted later today.

The functionality for register_shutdown_function under 4.0.x will be replaced with a function named apache_register_shutdown_function.  This should be available under 4.3.1 and later versions of PHP.  I will close this bug when the patch has been committed.

Closing as bogus.
If we ever support this kind of behavior, it won't be a part of register_shutdown_function().
If there was a working patch for apache_register_shutdown_function(), I missed it - please resend.