On Wed, Aug 14, 2019 at 12:55:01PM -0400, Rich Felker wrote: > On Wed, Aug 14, 2019 at 06:34:44PM +0200, Christian Brauner wrote: > > On Wed, Aug 14, 2019 at 06:15:17PM +0200, Christian Brauner wrote: > > > On Wed, Aug 14, 2019 at 06:09:17PM +0200, Oleg Nesterov wrote: > > > > On 08/14, Christian Brauner wrote: > > > > > > > > > > and a signal could come in between the system call that > > > > > retrieved the process gorup and the call to waitid that changes the > > > > ^^^^^ > > > > > current process group. > > > > > > > > I noticed this typo only because I spent 2 minutes or more trying to > > > > understand this sentence ;) But yes, a signal handler or another thread > > > > > > I'll try to rewrite it. :) > > > > Ok, here's what I changed it to: > > > > It was recently discovered that the linux version of waitid is not a > > superset of the other wait functions because it does not include > > support for waiting for the current process group. This has two > > downsides: > > 1. An extra system call is needed to get the current process group. > > 2. After the current process group is received and before it is passed > > to waitid a signal could arrive causing the current process group to > > change. > > I don't think "downsides" sufficiently conveys that this is hard > breakage of a requirement for waitpid. How about something like the > following? > > "It was recently discovered that the linux version of waitid is not a > superset of the other wait functions because it does not include > support for waiting for the current process group. Userspace cannot > simply emulate this functionality with an additional getpgid syscall > due to inherent race conditions that violate the async-signal safety > requirements for waitpid."
I like the rather specific example in there. How about we add that after this section like so: It was recently discovered that the linux version of waitid is not a superset of the other wait functions because it does not include support for waiting for the current process group. This has two downsides: 1. An extra system call is needed to get the current process group. 2. After the current process group is received and before it is passed to waitid a signal could arrive causing the current process group to change. Such inherent race-conditions as mentioned in 2. make it impossible for userspace to emulate this functionaly and thus violate the async-signal safety requirements for waitpid. Christian