Creating a second process

[neoform]

What's the easiest way for a script to spawn a second process?

 

I want to run something at the end of a pageload, but I don't want the user's browser to keep "loading" even after all the content has been sent.

 

If i do die() the browser stops loading, but the script is dead.

 

I noticed this: http://bugs.php.net/bug.php?id=29846

 

but, I'm wondering if there's a way around this..

[kratsg]

Let me get this correct. You first process the content and have it ready to display on the page. You want to display this content (so the page loads with the content) AND THEN continue with more PHP processing?

 

I've seen this hack before, a long time ago, I've spent hours scouring the web looking for it again, but I can't find it. However, another (more readily) solution is to use AJAX with an onload function to call a PHP page. This may be more feasible for your problem.

[neoform]

that relies on the user to load the secondary process, which is unreliable..

 

but yeah, i want to continue running the script after the browser output is complete. from what I can tell there's no efficient way to do this.

 

I was thinking of doing something really weird, like opening a stream to a url with that process code, which ignores timeout..  fopen(url), then right away fclose()..

 

but that seems really cumbersome.

[kratsg]

PHP is what PHP does. PHP is a HyperText Pre-Processor which means it will always run before a page is loaded (thank god it runs at super-speed xD)

 

that relies on the user to load the secondary process, which is unreliable..

 

No it doesn't. All it relies on is that the user has javascript enabled. You can stick AJAX under a document.onload = runajax; and run it from there, and that doesn't require a user to do anything (you won't even see "Page Loading..." in the browser while the AJAX is calling the PHP page.)

[neoform]

that's unreliable.

 

reliable is knowing the script *will* run no matter what. not crossing your fingers hoping the user has javascript enabled..

 

 

[kratsg]

that's unreliable.

 

reliable is knowing the script *will* run no matter what. not crossing your fingers hoping the user has javascript enabled..

 

 

 

You do realize you can check to see if the user has javascript enabled? You can have two schemas, one that runs the PHP completely, then outputs the page (for those w/o javascript) and then one that outputs and uses JavaScript to run the rest of the PHP.

[neoform]

Eitherway, it's bad policy to have something critical depend on the user.

 

I'd much rather a method whereby the server handles the process completely independent of the user.

 

register_shutdown_function() was a good way to do this, but it's function has been crippled and I need a new way to do what it did..

[kratsg]

Looking at the function, it's almost like the output buffers in controlling data, but there is no way to control what to run after you stop processing the PHP... Most likely because of a security issue (someone probably found a way around this or something, stopped it from running).

[laffin]

<?php
  // turn on buffering
  ob_start();
  // do our page thing
  echo "this will diaply in yer window";

  // get the buffer and length
  $output=ob_get_contents();
  $olen=ob_get_length();
  // stop buffering
  ob_end_clean();
  // tell browser when how big the contents of our page is
  header("Content-length: $olen");
  //output the page
  echo $output;
  // the following shud not display in the browser, reason using the file sample.txt as proof it continues processing
  $fh=fopen("sample.txt","w+");
  fwrite($fh,$msg="This shud not display in yer window, thus the script is still executing\n");
  fclose($fh);
  echo $msg;
?>

[neoform]

yeah, the ob_flush was is another way to go....

[laffin]

oops forgot some more things on it

<?php
  // turn on buffering
  ob_start();
  // do our page thing
  echo "this will diaply in yer window";

  // get the buffer and length
  $output=ob_get_contents();
  $olen=ob_get_length();
  // stop buffering
  ob_end_clean();
  // tell browser when how big the contents of our page is
  if($olen<256) {$output = str_pad($output, 256);$olen=256;} // IE Hack
  header("HTTP/1.1 200 OK");
  header("Content-Length: $olen");
  //output the page
  echo $output;
  // the following shud not display in the browser, reason using the file sample.txt as proof it continues processing
  $fh=fopen("sample.txt","w+");
  fwrite($fh,$msg="This shud not display in yer window, thus the script is still executing\n");
  fclose($fh);
  echo $msg;
?>

 

that shud work

[neoform]

doesn't using ob_flush commands slow down the page since it has to cache the output and display it on command instead of doing it naturally?

[laffin]

if yer processing so much info that it's noticeable by a wristwatch.

than it's not a question if ob commands causing a bottleneck in yer app.

it's a question of how do u optimize yer code.

 

pages shudn take more than a few secs to load.

[resago]

you could use exec, depending on the kind of processing you needed.

if running on a windows server, exec ("start whatever.php");

 

or on linux, exec ("whatever.php &");

 

 

[laffin]

windows dusn offer the nicety of having Shebang.

you will have to give it the php cli as well.

[neoform]

I'm trying to make a cron job system, this has nothing to do with code efficiency..

[neoform]

apparently "forking" is the way to do this..  but after reading about it..

 

Note: This extension is not available on Windows platforms.

 

which makes it useless since i don't like writing platform specific code.. :S