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: Torvald Riegel <triegel at redhat dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 03 Feb 2016 13:06:44 +0100
- 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>
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.