-
Notifications
You must be signed in to change notification settings - Fork 373
[CLI] Spawn OS processes for PHP subprocesses in Blueprint V2 worker #3004
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
adamziel
wants to merge
24
commits into
trunk
Choose a base branch
from
do-max-1-php-instance-per-cli-worker-v2
base: trunk
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+631
−213
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
PHPRequestHandler now always creates its own PHPProcessManager internally. The configuration is simplified to always require a phpFactory callback, removing the union type that allowed passing either a processManager or a phpFactory. This reduces API surface and complexity since no callers were using the custom processManager option.
Introduces a PHPInstanceManager interface that abstracts PHP instance lifecycle management. Both PHPProcessManager (for web contexts with multiple concurrent instances) and the new SinglePHPInstanceManager (for CLI contexts with a single instance) implement this interface. PHPRequestHandler now accepts either: - instanceManager: A pre-built PHPInstanceManager instance - phpFactory + maxPhpInstances: Creates PHPProcessManager internally This allows CLI contexts to use a simpler single-instance manager where runtime rotation is handled separately via php.enableRuntimeRotation(), while web contexts continue using PHPProcessManager for concurrency.
The spawnHandler callback parameter is now typed as PHPInstanceManager instead of PHPProcessManager to align with the interface abstraction.
PHPRequestHandler now supports three configuration options: - instanceManager: Custom PHPInstanceManager (advanced) - php: Single PHP instance (creates SinglePHPInstanceManager internally) - phpFactory + maxPhpInstances: Factory function (creates PHPProcessManager) When a php instance is provided directly, the same transformations (mkdir documentRoot, chdir, set requestHandler) are applied as with phpFactory, keeping the behavior consistent.
Simplify PHPRequestHandler configuration to only two options: - php: Single PHP instance (creates SinglePHPInstanceManager internally) - phpFactory + maxPhpInstances: Factory function (creates PHPProcessManager) The instanceManager option was overly complex for actual use cases.
The AcquiredPHP type better describes what the interface represents: a PHP instance that has been acquired from the instance manager and must be reaped when done. SpawnedPHP is now a backwards-compatible type alias exported from index.ts.
Base automatically changed from
do-max-1-php-instance-per-cli-worker
to
trunk
December 9, 2025 21:57
The sandboxedSpawnHandlerFactory now expects a getPHPInstance callback. Update boot.ts to use instanceManager instead of processManager and add a null check for requestHandler.
When PHP calls proc_open() to spawn a subprocess, each subprocess now runs in a separate Node.js worker thread. This ensures OS-level file locks via fcntl() and LockFileEx() properly conflict between parent and child processes, matching native PHP behavior. This is the V2 counterpart to the V1 worker change in PR #3001.
Pass the options object directly instead of destructuring and reconstructing it.
69e8dd5 to
a3aaff1
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
This is the V2 counterpart to PR #3001. When PHP calls
proc_open()to spawn a subprocess (like WP-CLI calling PHP), we need to ensure those subprocesses don't interfere with the parent's file locks.Previously in the V2 worker,
sandboxedSpawnHandlerFactorywas passed directly without a callback to create new OS processes. Subprocesses ran as new PHP instances within the same Node.js worker, which meant OS-level file locks (viafcntl()andLockFileEx()) could overlap between parent and child.This PR applies the same pattern from the V1 worker: spawning each subprocess in a separate Node.js worker thread running
worker-thread-v2.ts.Implementation
The
bootRequestHandlermethod now wrapssandboxedSpawnHandlerFactorywith a callback that:spawnWorkerThread('v2')bootWorker()Testing
This change affects the experimental Blueprint V2 runner. Run WP-CLI commands that spawn subprocesses: