Add support for watching processes with IOCP #73
Conversation
watcher: Add support for watching processes using IOCP
Previously, there was a race condition in the IOCP process watcher where if the process exited before wait() was called, it would hang indefinitely. I addressed this by adding a new result type for when a job is associated with the completion port, and calling the callback with this result so that the user code has a chance to check any invariants. Changes: - Call the completion callback when the job is associated with the IOCP - Add a test that tests the case of the process exiting before the wait() call - Rework job object handling to not require @unionInit. The user code can now interpret the message data however they want
|
Just pushed a change fixing the race condition mentioned in the PR description, see the commit message for details. Moving this out of draft status now. |
|
Looks great. We're getting regular errors (retried a couple times) in CI. Any thoughts on those? |
|
I don't see those locally, but it might be because the process tree in the CI is running under a job object itself - probably to control resource limits. I'll see if I can reproduce the same conditions locally and rework the logic to test if the process is already in a job object, and use that one instead. |
Thanks. Also happy to reconfigure CI if you have a way to do that. Either way, I'd love for the CI to pass. 😄 |
|
I'm not sure until this CI run happens, but I think the issue was trying to set the I did this initially because it would avoid having to handle (and ignore) events from any subprocesses. I reworked the logic to not set this, and just check the PIDs instead. |
kcbanner
force-pushed
the
iocp_process
branch
from
215233e
to
908155e
Compare
|
Awesome. Thank you! |
These changes add support for receiving events from JobObjects (https://learn.microsoft.com/en-us/windows/win32/procthread/job-objects) in the IOCP backend.
This feature is then used to implement an IOCP process watcher.
JobObjects are unique with the way they interact with the
OVERLAPPED_ENTRYresult structure - they completely repurpose all the fields to mean different things. This means I fill in the completion result directly beforeperformis called. Let me know if this is an issue, I could reworkperformto accept the entry itself.Remaining TODOs:
waitis called - there will be no completion events on the JobObject in this case