This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3 2/2] posix: Use posix_spawn on system
- From: Florian Weimer <fweimer at redhat dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 30 Nov 2018 16:21:36 +0100
- Subject: Re: [PATCH v3 2/2] posix: Use posix_spawn on system
- References: <20181025174103.31596-1-adhemerval.zanella@linaro.org> <20181025174103.31596-2-adhemerval.zanella@linaro.org> <87k1kvzsxd.fsf@oldenburg.str.redhat.com> <68bde1a2-ba4d-b3b0-389a-bc70a6b23ed5@linaro.org>
* Adhemerval Zanella:
> On 29/11/2018 15:37, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> +/* We have to and actually can handle cancelable system(). The big
>>> + problem: we have to kill the child process if necessary. To do
>>> + this a cleanup handler has to be registered and it has to be able
>>> + to find the PID of the child. The main problem is to reliable have
>>> + the PID when needed. It is not necessary for the parent thread to
>>> + return. It might still be in the kernel when the cancellation
>>> + request comes. Therefore we have to use the clone() calls ability
>>> + to have the kernel write the PID into the user-level variable. */
>>
>> This comment does not look relevant to me anymore.
>
> I think it still worth to mention glibc system aims to be thread-safe,
> which requires restore the signal dispositions for SIGINT and SIGQUIT
> correctly and to deal with cancellation by terminating the child process.
> +/* This system implementation aims to be thread-safe, which requires restore
> + the signal dispositions for SIGINT and SIGQUIT correctly and to deal with
> + cancellation by terminating the child process. */
I don't think you restore SIGINT and SIGQUIT correctly for concurrent
system calls. This is what the ADD_REF code in the old version
attempted to do.
Thnaks,
Florian