This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2 3/3] posix: New Linux posix_spawn{p} implementation


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]