Bug #15209 Updated: Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x

ID: 15209 Updated by: cam@wecreate.ca Reported By: priebe@mi-corporation.com Status: Open Bug Type: Output Control Operating System: RH Linux 7.2 PHP Version: 4.1.x - 4.2.1 New Comment: 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 :) Previous Comments: ------------------------------------------------------------------------ [2002-06-11 12:38:38] sts@mail.xubion.hu > 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. ------------------------------------------------------------------------ [2002-06-07 11:48:55] jtate@php.net 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? ------------------------------------------------------------------------ [2002-06-07 11:38:48] zeev@php.net 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. ------------------------------------------------------------------------ [2002-06-03 15:59:29] jtate@php.net 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 ------------------------------------------------------------------------ [2002-06-03 09:46:38] priebe@mi-corporation.com 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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/15209 -- Edit this bug report at http://bugs.php.net/?id=15209&edit=1