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

[Lennart Poettering]

On Wed, 12.07.17 09:53, Florian Weimer (fw at deneb.enyo.de) wrote:

> * 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.

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