* 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. > 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. > 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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel