This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] posix: Do not use WNOHANG in waitpid call for Linux posix_spawn
- From: Pedro Alves <palves at redhat dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Florian Weimer <fweimer at redhat dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, libc-alpha at sourceware dot org
- Cc: nd at arm dot com
- Date: Mon, 23 Oct 2017 16:11:26 +0100
- Subject: Re: [PATCH] posix: Do not use WNOHANG in waitpid call for Linux posix_spawn
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com CEC10806AB
- References: <1508705517-31558-1-git-send-email-adhemerval.zanella@linaro.org> <df710a9e-34ab-277f-973a-064db988fa3d@redhat.com> <59EDC6B6.2020005@arm.com>
On 10/23/2017 11:38 AM, Szabolcs Nagy wrote:
> VFORK is not precise (i think under ptrace parent can
> continue before child execs)
It can not, modulo ancient kernel bugs, perhaps. Even if the
ptracer PTRACE_CONTs the parent, the parent remains frozen
in "D (disk sleep)" until the child execs or dies, at which
point the ptracer is notified with a PTRACE_EVENT_VFORK_DONE
event, if enabled with PTRACE_O_TRACEVFORKDONE.
(GDB has to be careful to avoid resuming a vfork parent if not
resuming the child, otherwise the whole debug session deadlocks,
and Ctrl-C won't unblock it (because the parent/child's process
group would be made the foreground process group on resumption
and that's where the kernel would be sending the SIGINT. Since
the parent nor the child are scheduled, the SIGINT remains
pending forever.)
Now, if a multi-threaded program vforks, then all other
non-parent threads in the parent continue running. Only
the thread that vforked is frozen. But you're likely already
considering that undefined behavior.
> so using close-on-exec fd is a better way to sync with exec.
Thanks,
Pedro Alves