musl/src/process/waitpid.c

#include <sys/wait.h>
#include "syscall.h"
#include "libc.h"

pid_t waitpid(pid_t pid, int *status, int options)
{
	int r;
	CANCELPT_BEGIN;
	r = syscall(SYS_wait4, pid, status, options, 0);
	if (r<0) CANCELPT_TRY;
	CANCELPT_END;
	return r;
}
initial check-in, version 0.5.0 2011-02-12 00:22:29 -05:00			`#include <sys/wait.h>`
			`#include "syscall.h"`
overhaul cancellation to fix resource leaks and dangerous behavior with signals this commit addresses two issues: 1. a race condition, whereby a cancellation request occurring after a syscall returned from kernelspace but before the subsequent CANCELPT_END would cause cancellable resource-allocating syscalls (like open) to leak resources. 2. signal handlers invoked while the thread was blocked at a cancellation point behaved as if asynchronous cancellation mode wer in effect, resulting in potentially dangerous state corruption if a cancellation request occurs. the glibc/nptl implementation of threads shares both of these issues. with this commit, both are fixed. however, cancellation points encountered in a signal handler will not be acted upon if the signal was received while the thread was already at a cancellation point. they will of course be acted upon after the signal handler returns, so in real-world usage where signal handlers quickly return, it should not be a problem. it's possible to solve this problem too by having sigaction() wrap all signal handlers with a function that uses a pthread_cleanup handler to catch cancellation, patch up the saved context, and return into the cancellable function that will catch and act upon the cancellation. however that would be a lot of complexity for minimal if any benefit... 2011-03-24 14:18:00 -04:00			`#include "libc.h"`
initial check-in, version 0.5.0 2011-02-12 00:22:29 -05:00
			`pid_t waitpid(pid_t pid, int *status, int options)`
			`{`
overhaul cancellation to fix resource leaks and dangerous behavior with signals this commit addresses two issues: 1. a race condition, whereby a cancellation request occurring after a syscall returned from kernelspace but before the subsequent CANCELPT_END would cause cancellable resource-allocating syscalls (like open) to leak resources. 2. signal handlers invoked while the thread was blocked at a cancellation point behaved as if asynchronous cancellation mode wer in effect, resulting in potentially dangerous state corruption if a cancellation request occurs. the glibc/nptl implementation of threads shares both of these issues. with this commit, both are fixed. however, cancellation points encountered in a signal handler will not be acted upon if the signal was received while the thread was already at a cancellation point. they will of course be acted upon after the signal handler returns, so in real-world usage where signal handlers quickly return, it should not be a problem. it's possible to solve this problem too by having sigaction() wrap all signal handlers with a function that uses a pthread_cleanup handler to catch cancellation, patch up the saved context, and return into the cancellable function that will catch and act upon the cancellation. however that would be a lot of complexity for minimal if any benefit... 2011-03-24 14:18:00 -04:00			`int r;`
			`CANCELPT_BEGIN;`
			`r = syscall(SYS_wait4, pid, status, options, 0);`
			`if (r<0) CANCELPT_TRY;`
			`CANCELPT_END;`
			`return r;`
initial check-in, version 0.5.0 2011-02-12 00:22:29 -05:00			`}`