Tags: oconnor663/duct.rs
Tags
version 1.1.0 Changes since 1.0.0: - Added the `Handle::wait_timeout` and `Handle::wait_deadline` methods. These are gated by the `timeout` feature, which is enabled by default. Windows supports these timeouts natively, but on Unix this requires handling `SIGCHLD`. - Fixed a bug with setting or removing non-uppercase env var names on Windows. Duct previously uppercased all env var names passed to its API, but not names coming from the system environment, which caused mismatches. See #119. Contributed by @Wazzaps.
version 1.0.0 Changes since 0.13.7: - The API is stabilized as-is, and most callers won't need to make any changes. - Fixed a bug where `Handle::try_wait` could block indefinitely if a child process had exited but a longer-lived grandchild process was keeping its IO pipes open and its IO threads running (i.e. `stdin_bytes`, `stdout_capture`, or `stderr_capture`). Commit 04c2c8c. - `Handle` now does lazy cleanup of leaked zombie children. If a child has not exited by the time its `Handle` is dropped, that child gets added to a global list. Whenever any Duct function is about to spawn a new child, it polls each child in the leaked list and cleans up any that have exited. This strategy is copied from Python's `subprocess` module. `ReaderHandle` contains a `Handle` internally and does the same cleanup. - With that new cleanup mechanism in place, `Handle::kill` and `ReaderHandle::kill` no longer wait on child processes to exit. This avoids obscure edge cases (FUSE filesystems, debugger pauses) where waiting after `SIGKILL` could still block indefinitely. - Duct no longer kills your child processes in any circumstance other than when you call `.kill()`. Previously Duct would kill child processes when dropping a `ReaderHandle`, or in rare pipe spawning error cases.
PreviousNext