Hi Kirill!
On 03/17/2017 10:30 AM, Kirill Tkhai wrote:
> 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.
No, this is just one example. "In particular" does not mean that this is the
only case
where this applies, just a very noteworthy one. It's not exclusive to this case.
> 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?
Yes, but I'd still argue that the overall statement for getpid() is "We don't
guarantee
that the information provided by getpid() is correct and we therefore recommend
you
to use the syscall." Whether this flag makes a difference to the overall
reliability
of getpid() or not is questionable.
I did a quick check on Jessie and it seems that at least the statement for
CLONE_VM
is true there, although as you can see from the output below, the process
scheduling
from the kernel side seems to be different with the terminal output already
returning
to bash before the child has a chance to print to the terminal:
glaubitz@jessie64:~> ./clone
parent: pid=1320
parent: fork pid=1321
glaubitz@jessie64:~> 1)child: pid=1321
2)child: pid=1321
I would suggest filing a bug report to glibc upstream or posting on their
mailing list
to ask for feedback. I honestly don't know how acceptable the stale cache data
with
CLONE_VM is, but since the documentation already recommends to using the
syscall, I
think its safe to ignore this behavior:
> To get the truth, it may be necessary to use code such as the following:
>
> #include <syscall.h>
>
> pid_t mypid;
>
> mypid = syscall(SYS_getpid);
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
