On Mon, 10.07.17 14:04, vcap...@pengaru.com (vcap...@pengaru.com) wrote: > > > Except there's always a risk of these things regressing to normal > > > syscalls, > > > and one has to weigh the utility against that. It's unclear to me what > > > significant utility having the sd-journal API police changing pids by > > > calling getpid() at every public entrypoint is bringing to the table. > > > > So it seems the issue has been fixed in glibc upstream more than a year > > ago, and it doesn't seem to make sense to optimize current systemd git for > > that. > > > > Can you provide a commit id? I took a glance at > sourcewaire.org/git/gitweb.cgi > for getpid commits and didn't see anything relevant since the removal[1]. > > > > I see the argument that the getpid() checks are a bit excessive. Is their > > overhead actually noticeable with current glibc? > > > > On my spare arch system I still see gratuitous getpid() calls from > journalctl, which is on glibc 2.5-2. > > The pollution of strace output alone due to these checks is nuisance enough > for me to want the checks removed, considering their only value is to catch > programmer errors. There's an abundance of potential programmer errors > we're not making any effort to prevent, why is this one so privileged that > it warrants policing?
strace doesn't show getpid() calls if they are properly cached. While stracing journalctl I never have seen a single one of them... > I appreciate Lennart's point about the hazards of forking from threaded > programs. It just doesn't seem like a valid rationalization for sprinkling > a system library's entrypoints with getpid() calls to catch this in > production. Normally it's dead cheap to check that, it's just reading and comparing one memory location. It's a pitty that this isn't the case currently on Debian, but as it appears this is an oversight on their side, and I am sure it will be eventually fixed there, if it hasn't already. > Considering the associated potential costs, and the historic controversy > surrounding the caching of this particular syscall[2] I'm a bit confused by > the status quo. Well, normally there's next to no cost to this, on pretty much any non-Debian distro there isn't any price for this to pay... I mean, we could certainly cache that value in our code too, but given that glibc does that already in the normal case I think this is better left to be fixed in glibc rather than our code. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
