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 roland/getpid] Simplify getpid handling of the race case.


On Sat, May 10, 2014 at 09:01:46AM +0200, Petr Salinger wrote:
> Hi.
> 
> >This is implemented by a few lines of assembly for each
> >machine, and nowhere is there a comment that explains the rationale.
> 
> I tried to understand this hackery during porting nptl to kFreeBSD.
> 
> >The difference is that in the libc version, it checks for ->pid
> >being zero and if it's zero instead sets it to 0x80000000 (i.e. an
> >arbitrary negative number).  The libpthread version doesn't do
> >that, so if it's set to zero then it stays that way.
> 
> Not really.
> 
> The ->pid (and ->tid) is zero after execve().
> With libpthread.so linked in, the __pthread_initialize_minimal runs.
> Therefore it is guaranteed that during fork() a vfork() the  ->pid
> is non-zero.
> 
> But without libpthread.so linked in, the ->pid (and ->tid) might be
> zero even during fork() a vfork() calls.
>
Another possibility here is offload this to kernel, it should be easy to
add getpid vdso. That would make libc caching redundant. Same thing could
be done with gettid vdso if we decide to add gettid wrapper.


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