Recently I was writing some code where I wanted to wait for a child process, and I wanted the wait call to have a timeout. 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).

There are a lot of "wait" system calls on Linux. In section 2 of the Linux man pages you get all of the following:

pid_t wait(int *wstatus); pid_t waitpid(pid_t pid, int *wstatus, int options); int waitid(idtype_t idtype, id_t id, siginfo_t *infop, int options); pid_t wait3(int *wstatus, int options, struct rusage *rusage); pid_t wait4(pid_t pid, int *wstatus, int options, struct rusage *rusage);

Wow, look at all of those ways to wait for a process! In reality, a lot of these are wrapper methods required by POSIX, or provided by glibc. Only two of these are true system calls on Linux: waitid() and wait4() . But that's still a lot of ways to wait for things.

As you can see, none of these accept a timeout. I Googled the question, and found a Stack Overflow post titled "Waitpid equivalent with timeout?". The top answer suggests using alarm() , which apparently is wrong. Of course it's wrong, if you've done a lot of Unix systems programming you'll know that alarm() is always the wrong answer. Then there are numerous other answers that go into crazy gymnastics to solve the problem. Modern Linux systems have a system call called signalfd() which allows you to register a file descriptor to receive signal events. With this technique, you can register a signalfd for SIGCHLD events, and then put it into an epoll or select loop with a timeout. This is a lot simpler than the other Stack Overflow answers, but is still kind of complicated. Furthermore, signalfd() wasn't added to Linux until 2007, with kernel 2.6.22. This is certainly old enough for pretty much all real world running Linux applications, but it's not a standard Unix feature and therefore isn't portable. On classic Unix systems you need to resort to the kind of tricks in the Stack Overflow post.

These poor API decisions come up more frequently in Unix than people like to admit. In fact, the reason there are so many "wait" calls available is because the original APIs were poorly designed, and had to be modified to be more flexible.

Things get even worse with a lot of the blocking I/O system calls. For instance, suppose you want to create a directory. You get two choices:

int mkdir(const char *pathname, mode_t mode); int mkdirat(int dirfd, const char *pathname, mode_t mode);

Neither of these takes a timeout, and neither of them exposes an interface that can be used with select or epoll. If you've ever had the mispleasure of reading the libuv source code you'll know that there's a trick to turning these kinds of I/O operations into something you can put into an event loop: you run the desired operation ( mkdir() in this case) in another thread, and then wait for the thread to finish with a timeout. I've been told it's common practice for vendors of things like NFS hardware appliances to patch the kernel (most likely BSD in this case) to add new system calls to make it possible to implement operations like this natively.

Hopefully one day we can redo all of the I/O stuff in Unix. But I'm not holding my breath.

Update: Henrique Almeida sent me the following email telling me about some system calls I was not familiar with:

Hello, if you need to wait with a timeout for a child to exit I think you should use sigprocmask with either pselect or sigtimedwait and wait for SIGCHLD. You don't need signalfd or alarm.