4 ms·

Not saying the syscall APIs are not broken, but what is a use case for wait() with timeout? Just curious...

deathanatos 10y ago
From the article's first paragraph: > The use case is something like this: you spawn a subprocess, and you expect the subprocess to complete within ten seconds. If it doesn’t complete in that time, you want to treat it as an error (and perhaps kill the child). I've had this exact use case myself, several times. It's painful.
- deleted 10y ago
  [deleted]
geofft 10y ago
Weirdly-behaved processes that get stuck (which is usually why you want it in a separate process in the first place). Things that come to mind include hardware utilities making ioctl()s, tools that fetch data from the network that don't have built-in functionality for timeouts, and untrusted code running inside a sandbox (e.g. https://play.rust-lang.org/ https://play.rust-lang.org/ with "fn main() {loop {}}"). You can sort of work around it by calling waitpid(...WNOHANG) every tenth of a second or so.
- klodolph 10y ago
  WNOHANG is a bit of a hack. It's more straightforward to wait for SIGCHLD or just call alarm().
  - tomjakubowski 10y ago
    Sure, it's probably a hack if you write a loop that looks like this: while (!waitpid(child_pid, &status, WNOHANG)) usleep(10); } But WNOHANG is perfectly fine, even necessary, if you're calling it from the body of some periodically scheduled event loop which you mustn't block, like in a video game or something.
    - klodolph 10y ago
      I think some of the context for "WNOHANG is a bit of a hack" got lost. > You can sort of work around it by calling waitpid(...WNOHANG) every tenth of a second or so. For event loops, you can still use SIGCHLD (which is portable) or signalfd (which integrates better into event loops). This avoids the extra syscall every loop through the event loop.
      - geofft 10y ago
        SIGCHLD (via a signal handler, signalfd, sigtimedwait, whatever) only tells you that some child exited, and also only one part of the process can deal with SIGCHLD. (You can't correctly compose a signal handler + signalfd.) waitpid on the specific pid will check that specific process and no others, and not interfere with any other part of the program that might be waiting for some other child.

From the article's first paragraph: > The use case is something like this: you spawn a subprocess, and you expect the subprocess to complete within ten seconds. If it doesn’t complete in that time, you want to treat it as an error (and perhaps kill the child). I've had this exact use case myself, several times. It's painful.

deleted 10y ago
[deleted]

geofft 10y ago

Weirdly-behaved processes that get stuck (which is usually why you want it in a separate process in the first place). Things that come to mind include hardware utilities making ioctl()s, tools that fetch data from the network that don't have built-in functionality for timeouts, and untrusted code running inside a sandbox (e.g. https://play.rust-lang.org/ https://play.rust-lang.org/ with "fn main() {loop {}}"). You can sort of work around it by calling waitpid(...WNOHANG) every tenth of a second or so.

klodolph 10y ago
WNOHANG is a bit of a hack. It's more straightforward to wait for SIGCHLD or just call alarm().
- tomjakubowski 10y ago
  Sure, it's probably a hack if you write a loop that looks like this: while (!waitpid(child_pid, &status, WNOHANG)) usleep(10); } But WNOHANG is perfectly fine, even necessary, if you're calling it from the body of some periodically scheduled event loop which you mustn't block, like in a video game or something.
  - klodolph 10y ago
    I think some of the context for "WNOHANG is a bit of a hack" got lost. > You can sort of work around it by calling waitpid(...WNOHANG) every tenth of a second or so. For event loops, you can still use SIGCHLD (which is portable) or signalfd (which integrates better into event loops). This avoids the extra syscall every loop through the event loop.
    - geofft 10y ago
      SIGCHLD (via a signal handler, signalfd, sigtimedwait, whatever) only tells you that some child exited, and also only one part of the process can deal with SIGCHLD. (You can't correctly compose a signal handler + signalfd.) waitpid on the specific pid will check that specific process and no others, and not interfere with any other part of the program that might be waiting for some other child.