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? So why then regress so badly? And what does getppid have to do with all this? > > 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? > > 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? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
