This is the mail archive of the 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.


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 linked in, the __pthread_initialize_minimal runs.
Therefore it is guaranteed that during fork() a vfork() the ->pid is non-zero.

But without linked in, the ->pid (and ->tid) might be
zero even during fork() a vfork() calls.

The nptl variant is just optimized with assumption that pid cannot be zero. The 0x80000000 is not arbitrary negative number, but the only
negative number, that does not have corresponding positive number
in 32 bits.

I'm not very clear on the utility of ever setting ->pid to a negative
value. The fork and vfork code never look at the negated value again, they just save the original value locally and restore it later.

See nptl/sysdeps/unix/sysv/linux/raise.c

The situation when both ->pid and ->tid are zero means,
that the program is single threaded (w/o linked in), fork/vfork does not run. Therefore it is the right time to store real pid into ->pid for future cached usage. Your change does not do that,
it is a significant regression.


Please CC me on reply, I am not subscribed to libc-alpha

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