mirror of
git://sourceware.org/git/newlib-cygwin.git
synced 2025-01-29 10:30:50 +08:00
86f79af827
This is a followup to a report back in 2011 about essentially the same issue: https://cygwin.com/ml/cygwin/2011-04/msg00031.html The same test program in that report demonstrates the issue, but with kill sending any non-zero signal. To reiterate, the problem here is POSIX compliance with respect to sending signals to zombie processes. http://pubs.opengroup.org/onlinepubs/9699919799/functions/kill.html claims: Existing implementations vary on the result of a kill() with pid indicating an inactive process (a terminated process that has not been waited for by its parent). Some indicate success on such a call (subject to permission checking), while others give an error of [ESRCH]. Since the definition of process lifetime in this volume of POSIX.1-2008 covers inactive processes, the [ESRCH] error as described is inappropriate in this case. In particular, this means that an application cannot have a parent process check for termination of a particular child with kill(). (Usually this is done with the null signal; this can be done reliably with waitpid().) In response to the originally issue, this was fixed *specifically* for the case of kill(pid, 0). But my reading of the above is that kill() should return 0 in this case regardless of the signal (modulo permissions, etc.). On Linux, for example, when calling kill with pid of a zombie process the kernel will happily deliver the signal to the relevant task_struct; it will just never be acted on since the task will never run again. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cygwin documentation is available on the net at https://cygwin.com You might especially be interested in https://cygwin.com/faq/faq.html#faq.programming.building-cygwin