Skip to content

[windows] tell a spawned analysis worker the pid its orchestrator knows it by - #2269

Open
jeremydubreil wants to merge 1 commit into
meta:mainfrom
jeremydubreil:windows-worker-pids
Open

jeremydubreil wants to merge 1 commit into
meta:mainfrom
jeremydubreil:windows-worker-pids

Conversation

@jeremydubreil

@jeremydubreil jeremydubreil commented Oct 24, 2026 •

Copy link
Copy Markdown
Contributor

On Windows, Unix.create_process returns a process handle rather than a process id. The orchestrator knows each spawned analysis worker by that value and takes locks on its behalf under it, while ProcLocker tells the locks a worker owns from the others by comparing it with the worker's own pid. The two never match, so a spawned worker does not recognize the locks taken for it.

This PR makes the orchestrator pass the pid it knows a spawned worker by to that worker, which then uses it instead of its own pid. Only workers started with Unix.create_process (--no-unix-fork, the default on Windows and macOS) are affected; forked workers (--unix-fork, the default on Linux) keep their own pid as before.

Testing on Linux, with both --unix-fork and --no-unix-fork, on WebGoat, WebGoat.NET, OWASP BenchmarkJava and Apache HBase: the reported issues are the same, and the analysis time shows no difference beyond the run-to-run variation.

@meta-cla meta-cla Bot added the CLA Signed label Oct 24, 2026
@jeremydubreil
jeremydubreil marked this pull request as ready for review October 26, 2026 11:01
@jeremydubreil
jeremydubreil force-pushed the windows-worker-pids branch 2 times, most recently from 62dccf7 to 06c2c45 Compare October 28, 2026 13:51

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant