This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 3/3] posix: New Linux posix_spawn{p} implementation
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 3 Feb 2016 10:14:25 -0200
- Subject: Re: [PATCH v2 3/3] posix: New Linux posix_spawn{p} implementation
- Authentication-results: sourceware.org; auth=none
- References: <1454343665-1706-1-git-send-email-adhemerval dot zanella at linaro dot org> <1454343665-1706-4-git-send-email-adhemerval dot zanella at linaro dot org> <56B0A9B7 dot 6000507 at redhat dot com> <56B0AFBB dot 4050402 at linaro dot org> <1454497614 dot 4592 dot 392 dot camel at localhost dot localdomain> <56B1ECEF dot 6060604 at linaro dot org> <1454501204 dot 4592 dot 393 dot camel at localhost dot localdomain>
On 03-02-2016 10:06, Torvald Riegel wrote:
> On Wed, 2016-02-03 at 10:05 -0200, Adhemerval Zanella wrote:
>>
>> On 03-02-2016 09:06, Torvald Riegel wrote:
>>> On Tue, 2016-02-02 at 11:31 -0200, Adhemerval Zanella wrote:
>>>>
>>>> On 02-02-2016 11:05, Florian Weimer wrote:
>>>>> On 02/01/2016 05:21 PM, Adhemerval Zanella wrote:
>>>>>
>>>>>> + new_pid = CLONE (__spawni_child, STACK (stack, stack_size),
>>>>>> + CLONE_VM | CLONE_VFORK | SIGCHLD, &args);
>>>>>
>>>>> Does this set up new per-thread variables? Otherwise, errno in the
>>>>> parent and child will be same and the code still has races.
>>>>>
>>>>> Florian
>>>>>
>>>>
>>>> Could you elaborate? In my understanding there is no requirement of
>>>> using CLONE_SETTLS to avoid races: CLONE_VFORK will suspend the
>>>> calling process and even with child using the same TLS namespace as
>>>> the parent there will be no concurrent access between them.
>>>
>>> Whatever you agree on eventually, it sounds as if this should be
>>> documented as part of the concurrency notes for this function.
>>>
>>
>> I think it is worth to comment internally on the function implementation
>> about the CLONE_VFORK synchronization, but since it is transparent
>> to user (the function will either spawn a new process or fails and it can
>> be either through a syscall, {v}fork/exec or any other mechanism),
>> I do not see why expose these implementation details explicit.
>
> I meant the internal documentation; IOW, comments in the code.
>
Fair enough, I will add them.