On 17.03.2017 02:07, John Paul Adrian Glaubitz wrote:
> Hi Kirill!
>
>> My case is not in the list of the cases, described in clone(2),
>> when wrong pid may be returned, so this is a BUG.
>
> Which case in particular do you mean? From the manpage it seems that
> getpid() is simply not reliable under various circumstances and that
> one should always use the syscall alternative if possible:
>
>> Versions of the GNU C library that include the NPTL threading library
>> contain a wrapper function for getpid(2)
>> that performs caching of PIDs. This caching relies on support in the glibc
>> wrapper for clone(), but as currently
>> implemented, the cache may not be up to date in some circumstances.
>
> Can you elaborate a bit more where your sample code contradicts the
> clone(2) manpage which documents the buggy behavior?
I interpret the below paragraph as the only "stale-cache" case:
>>In particular, if a signal is delivered to the child immediately after the
>>clone()
>>call, then a call to getpid(2) in a handler for the signal may return the
>>PID of the calling
>>process ("the parent"), if the clone wrapper has not yet had a chance to
>>update the PID cache in
>>the child.
Also, there is
>>The stale-cache problem also does not occur if the flags argument
>>includes CLONE_VM.
Isn't it the case of my test program?
Regards,
Kirill
