* Lennart Poettering: > On Wed, 12.07.17 09:53, Florian Weimer (f...@deneb.enyo.de) wrote: > >> * Lennart Poettering: >> >> > On Tue, 11.07.17 21:24, Florian Weimer (f...@deneb.enyo.de) wrote: >> > >> >> * Lennart Poettering: >> >> >> >> > This all stems from my experiences with PulseAudio back in the day: >> >> > People do not grok the effect of fork(): it only duplicates the >> >> > invoking thread, not any other threads of the process, moreover all >> >> > data structures are copied as they are, and that's a time bomb really: >> >> >> >> These days, the PID can change even without a fork, so the story is a >> >> bit different. >> > >> > Can you elaborate? >> >> I'm no longer sure that the PID can change with the current kernel, >> but I cannot rule it out, either. But other weirdness is possible: >> for example, after a fork, getpid and getppid could be equal. > > Please be less vague. So I understand correctly that the PID cannot > change without fork after all?
I don't know. I don't see such a guarantee provided by the kernel. I think the important aspect is that as far as glibc is concerned, the PID *can* change even if its fork and vfork functions are never called, so we cannot reliably invalidate a cache. We could decide that it is undefined to call the fork/vfork/clone system calls directly, but that would break systemd functionality, I think. >> > Are you talking about cases where you invoke clone() directly, instead >> > of via glibc's wrappers? We do that too in systemd, but I am not sure >> > this is really reason enough to introduce this regression in glibc: >> > this is easily worked around (which we do in systemd), and given that >> > the time between clone() and execve() should be short, and the >> > code between the two minimal this isn't really much of a problem. >> >> There are other uses of clone which do not immediately lead to an >> execve. > > Can you elaborate? Have a real-life user of this? src/nspawn/nspawn.c? A lot of things happen in the inner_child function. >> > Where was this discussed in detail? Do you have any links about the >> > discussions about this? >> >> It was on libc-alpha and the glibc bug tracker. > > Link? https://sourceware.org/ml/libc-alpha/2016-10/msg00136.html https://sourceware.org/ml/libc-alpha/2016-10/msg00233.html https://sourceware.org/ml/libc-alpha/2016-11/msg00247.html https://sourceware.org/ml/libc-alpha/2016-11/msg00303.html https://www.postgresql.org/message-id/e1ukzbn-0006c6...@gemulon.postgresql.org The last reason explains why using getpid for fork detection does not work in the way one would expect. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
