[systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Florian Weimer]

* Lennart Poettering:

> On Tue, 11.07.17 21:24, Florian Weimer (fw at 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.