Re: bin/108390: [libc] [patch] wait4() erroneously waits for all children when SIGCHLD is SIG_IGN [regression]

[Alan Ferrency <alan_(_at_)_pair_(_dot_)_com>]

> Further check on Solaris revealed that for the case where SIGCHLD is
> ignored, wait4() returned -1/ECHLD, conforming to the FreeBSD behaviour
> of reparenting to init.

If I'm interpreting Jilles' notes about this proposed patch, it seems
like this would solve our primary problem.

That is: we already receive a -1/ECHLD when we call wait4pid() as
expected, but we don't receive it in a timely manner if there are
other child processes still running.  If this patch causes wait4pid()
to return immediately when a nonexistent (exited) child PID is
specified, that would meet our expectations and preferences.

Regarding SA_NOCLDWAIT: it was previously my understanding that
SA_NOCLDWAIT and igoring SIGCHLD affect two different aspects of child
process management.  On a previous occasion when I looked into the
behavior of SA_NOCLDWAIT, it wasn't even implemented on Linux yet; but
obviously, ignoring SIGCHLD was supported.

Thanks for the patch, 
Alan Ferrency
pair Networks, Inc.

> Unless further comments are given, I will commit this in several days:
>
> diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c
> index 4255734..c35c6f2 100644
> --- a/sys/kern/kern_exit.c
> +++ b/sys/kern/kern_exit.c
> @@ -504,13 +504,13 @@ exit1(struct thread *td, int rv)
> 		proc_reparent(p, initproc);
> 		p->p_sigparent = SIGCHLD;
> 		PROC_LOCK(p->p_pptr);
> +
> 		/*
> -		 * If this was the last child of our parent, notify
> -		 * parent, so in case he was wait(2)ing, he will
> +		 * Notify parent, so in case he was wait(2)ing or
> +		 * executiing waitpid(2) with our pid, he will
> 		 * continue.
> 		 */
> -		if (LIST_EMPTY(&pp->p_children))
> -			wakeup(pp);
> +		wakeup(pp);
> 	} else
> 		mtx_unlock(&p->p_pptr->p_sigacts->ps_mtx);
_______________________________________________
freebsd-bugs_(_at_)_freebsd_(_dot_)_org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe_(_at_)_freebsd_(_dot_)_org"