You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem Pids in ProcessHandles is that on most system they are limited to 2^16 many by default. If you spawn many short-lived processes quickly, the pid namespace can wrap around and you will accidentally waitForProcess (wait()) on the wrong process, or terminateProcess the wrong one.
Linux 5.4 solves this with pidfds (which are per-process, and 32-bit many). They can point to zombie processes so they will never accidentally point to a different process.
The process library could use them on newer Linux by simply tracking the pidfd in a Maybe field inside ProcessHandle.
After being spawned, a pid can be converted to a pidfd using pidfd_open() -- but this is still slightly racy, and better is to get it atomically directly from clone(). But it's an easy migration path that's a strict improvement already.
pidfds can be waited on with select(), epoll() and so on, which means we can use the GHC IO manager to wait for them more efficiently than with the usual waitForProcess.
Linux 5.10 made pidfds nonblocking, thus making them much easier to use without additional threads, and probably direct integration into the IO manager:
Background:
The problem
Pid
s inProcessHandle
s is that on most system they are limited to 2^16 many by default. If you spawn many short-lived processes quickly, the pid namespace can wrap around and you will accidentallywaitForProcess
(wait()
) on the wrong process, orterminateProcess
the wrong one.Linux 5.4 solves this with pidfds (which are per-process, and 32-bit many). They can point to zombie processes so they will never accidentally point to a different process.
The
process
library could use them on newer Linux by simply tracking the pidfd in aMaybe
field insideProcessHandle
.pidfd
usingpidfd_open()
-- but this is still slightly racy, and better is to get it atomically directly fromclone()
. But it's an easy migration path that's a strict improvement already.select()
,epoll()
and so on, which means we can use the GHC IO manager to wait for them more efficiently than with the usualwaitForProcess
.This Rust library https://github.com/pop-os/pidfd shows how you can wait for a program to finish using
waitid()
.The text was updated successfully, but these errors were encountered: