-
Notifications
You must be signed in to change notification settings - Fork 743
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
Process polling #1853
base: master
Are you sure you want to change the base?
Process polling #1853
Conversation
Fixed (hopefully) the errors reported in CI. Had to use |
Thanks for approving the pipeline. Hopefully I fixed the flaky test :) It seems that leak sanitizer doesn't work with panicking tests, so I disabled them when compiled under this sanitizer. The error that we get here might be related to a custom allocator. I'm not sure EDIT I couldn't reproduce leak sanitizer error in the Docker container with Ubuntu 24.04 and Rust nightly. Not sure why it's happening in the CI. |
This PR adds process polling capabilities via
Process
type that implementsSource
.pidfd
.EVFILT_PROC
filter ofkqueue
.To implement
Process
I made the following changes.epoll
-based andpoll
-based selectors:pidfd
is like any other file descriptor.kqueue
-based selector and relatedis_*
functions to support newEVFILT_PROC
filter and prevent code repetition.lpCompletionKey
), and each selector maintains a mapping between the handles and the associated dataHandleInfo
. For processes the associated data consists of user-provided token. Currently only processes are registered as handles, but everything else can be re-implemented using handles to simplify the code (e.g.Arc<CompletionPort>
will no longer be needed inNamedPipe
and it will be possible to register the same pipe in several selectors). Please let me know if this is something you want to be done in this PR.tests/process.rs
test.tests/util
module to support large number of events.Besides process polling this PR includes fixes suggested by the latest Clippy version.
EDIT
The motivation behind non-blocking process polling is to simplify projects that use
mio
to collect output from child processes (e.g. test harnesses, virtual networks). Currently such projects either use a separate thread to wait for child processes viawait
syscall (that waits for any process to exit) orpoll
with small timeout and check whether the processes exited after eachpoll
. The former needs mutexes to synchhorinze the waiting thread with the poller, and the latter is as efficient as active polling. With proper process polling such projects would use the same thread to monitor process status, this would greatly simplify their code bases.EDIT 2
I tested the changes on Linux, MacOS, FreeBSD and Windows using the same commands as in CI and latest Rust version.