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

[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?

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.

Where was this discussed in detail? Do you have any links about the
discussions about this?

Lennart

-- 
Lennart Poettering, Red Hat