PHP后台进程自杀

I have a PHP class that I use to run php script files in background, like this:

Class BackgroundScript{
    public $win_path = "C:\\xampp\\htdocs\\www\\project";
    public $unix_path = "/home/my_folder/project.com";
    public $script = NULL;
    public $command = NULL;
    public $pid = NULL;
    public $start_time = NULL;
    public $estimated_time = NULL;
    public $ellapsed_time = NULL;
    public $status_file = NULL;
   ...

  public function kill(){
        $this->removeFile();
        if ( self::get_os() == "windows" ){
            shell_exec(" taskkill /PID ".$this->pid);
        } else{
             shell_exec('kill '.$this->pid);
        }
    }
}

That is called this way:

$argvs = " var1 var2 ";
$process = new BackgroundScript("controller.php processCSV $argvs");

Then, it creates a process that runs in background a code similar to this:

$current_process = BackgroundProcess::getByPID(getmypid());
for ($=1; $i< 100; $i++){
   performLongRunningTask();
   $current_process->updateStatus();
}

What I want to know is, is possible to add at the end of the loop, the following command:

$process->kill();

Considering that this php file is executed by the process I want to kill? And are there any side effects I should contemplate?

For windows you can use /F to force the kill:

taskkill /F /PID YOUR_PID

For linux you can use the syntax: kill [signal or option] PID(s) The options you can use are:

SIGHUP      1       Hangup (the default and safest way to kill a process)
SIGKILL     9       Kill Signal (less secure way of killing a process)
SIGTERM     15      Terminate (the most unsafe way to kill a process which terminates a process without saving)

When you use kill '.$this->pid it will send a SIGTERM signal. A few things can happen here:

• the process may stop immediately
• the process may stop after a short delay after cleaning up resources
• the process may keep running indefinitely

The application can determine what it wants to do once a SIGTERM is received. While most applications will clean up their resources and stop, some may not. An application may be configured to do something completely different when a SIGTERM is received. Also, if the application is in a bad state, such as waiting for disk I/O, it may not be able to act on the signal that was sent.