Once upon an API

Back in 1997, a new system call, prctl(), was added to the Linux kernel. By now that API does many (arguably, too many) different things to a process. But to begin with, it provided just one feature: …

Back in 1997, a new system call, prctl(), was added to the Linux kernel. By now that API does many (arguably, too many) different things to a process. But to begin with, it provided just one feature: to allow a child process to request that the kernel send it a signal when its parent dies. At first, the PR_SET_PDEATHSIG feature seems simple.However, when one examines its interactions with various other UNIX and Linux API features, such as threads, signals, and exec, the semantics of this feature turn out to be at times both complex and surprising. Some of those semantics were certainly unintended, and are bizarre enough that, as the Linux man-pagesmaintainer, I fear documenting them. By looking in detail at this specific example, I’ll explore various pitfalls and lessons we can learn when designing APIs, philosophize a little on the question of who “owns” an API when it comes to defining the semantics of that API, and consider some strategies for improving the API design process.