Implementing parallelism without using pcntl_fork?

[morrisonlevi]

Currently, the parallelism for phpcs is achieved via pcntl_fork. Fork without exec has a variety of problems, and I hit some of those recently in an extension I maintain. I need to fix it; it's not phpcs's problem. However, in the interest of moving the community forward instead of just fixing my problem, I thought I'd open this discussion.

The main way to fix these issues on Linux today is to exec after forking. This is what proc_open does. In the future there may be better ways to avoid forking like using io_uring_spawn, but we don't have that today.

Has anyone experimented with using proc_open instead of pcntl_fork for parallelism in phpcs in the past? If not, does anyone more familiar with the codebase than I am have any insight for what might make it difficult? Theoretically this move would help out with portability too, so it may be valuable aside from the issue with pcntl_fork.

There's also a possibility to use something like Symfony's PhpProcess to make it easier too. Any opposition to doing something like that?

[jrfnl]

@morrisonlevi I haven't looked into the potential implementation for PHPCS, but from working with proc_open elsewhere, I see a number of potential issues:

• pcntl_fork forks the current process, while proc_open would create completely new processes.
• In effect, this may create problems with the default PHP version on a system vs the PHP version the user chose to run PHPCS on.
• Similar, the PHPCS executable used may be a specific one, while there is another PHPCS executable in the system path, which can screw things up.
• And worst of all: error handling. Notices, warning, deprecations etc in those new processes will be significantly more "hidden" and more difficult to detect and debug.

A good implementation can, of course, work round these issues, but it is definitely more complex and the performance overhead of those work-arounds may not be worth making the change.

As for using something like Symfony's PhpProcess - I can't speak for the project, but from past experience I have the strong impression that the project does not want any runtime (non-dev) external dependencies.