简介

PHP的进程控制支持实现了Unix方式的进程创建, 程序执行, 信号处理以及进程的中断。进程控制不能被应用在Web服务器环境，当其被用于Web服务环境时可能会带来意外的结果。

这份文档用于阐述每个进程控制函数的通常用法。关于Unix进程控制的更多信息建议您查阅系统文档中关于fork（2）,waitpid（2），signal（2）等的部分或更全面的参考资料比如《Unix环境高级编程》（作者：W. Richard Stevens，Addison-Wesley出版）。

PCNTL现在使用了ticks作为信号处理的回调机制，ticks在速度上远远超过了之前的处理机制。这个变化与"用户ticks"遵循了相同的语义。您可以使用declare() 语句在程序中指定允许发生回调的位置。这使得我们对异步事件处理的开销最小化。在编译PHP时启用pcntl将始终承担这种开销，不论您的脚本中是否真正使用了pcntl。

有一个调整是PHP 4.3.0之前的所有pcntl脚本要使其工作，要么在期望允许回调的（代码）部分使用 declare() ，要么使用declare()新的全局语法使其在整个脚本范围有效。

Note: 此扩展在 Windows 平台上不可用。

User Contributed Notes

InvisibleSmiley 09-Nov-2020 08:34


The disabling of pcntl functions not only affects Apache servers but any non-CLI setup, e.g. nginx with PHP-FPM.



You can tell by issuing phpinfo() and looking at "disable_functions" in the Core section of the output.



It's also worth noting that this behavior can be quite misleading when you call one of the pcntl functions in a namespaced context. For example you may get:



"Call to undefined function some\custom\namespace\pcntl_signal()"



when calling pcntl_signal from a method within a namespaced class. Your first instinct may be to add a leading backslash, but that won't solve the problem. You need to check whether the function exists at runtime, unless the code is only ever executed from the CLI.

Rick Sustek 15-Jun-2016 09:02


Actually it makes perfect sense why process control features are not supported for the Apache module. The Apache HTTP server is the chief process. It invokes the PHP module when steered to PHP by the resource requested (e.g. http://foo.php) It invokes the PHP module, typically on a new thread or a pooled thread. The PHP module then runs your script, but Apache server is still the owning process.



In this execution model, the job of your PHP script is generally to go about its business as fast as possible and return. This allows the Apache daemon to do something else useful with the thread it let you borrow. Yes, some scripts take longer to do their duty than others, but blocking the thread for extended periods is usually frowned upon.



If your script was allowed to mess with the signal handlers of the running process, it would be messing with the Apache daemon itself! That daemon has already installed signal handlers for its own use. It is just plain sense not to allow the process control operations in this context.

sean dot kelly at mediatile dot com 09-Jan-2012 01:32


The following statement left me searching for answers for about a day before I finally clued in:



"Process Control should not be enabled within a web server environment and unexpected results may happen if any Process Control functions are used within a web server environment."



At least for PHP 5.3.8 which I am using, and who knows how far back, it's not a matter of "should not", it's "can not". Even though I have compiled in PCNTL with --enable-pcntl, it turns out that it only compiles in to the CLI version of PHP, not the Apache module. As a result, I spent many hours trying to track down why function_exists('pcntl_fork') was returning false even though it compiled correctly. It turns out it returns true just fine from the CLI, and only returns false for HTTP requests. The same is true of ALL of the pcntl_*() functions.