4 ms·
The best part of this thread was the link to the discussion on the removal of pid caching in `getpid` causing regressions in systemd https://bugzilla.redhat.com
by flakes 3y ago
The best part of this thread was the link to the discussion on the removal of pid caching in `getpid` causing regressions in systemd https://bugzilla.redhat.com/show_bug.cgi?id=1469670 https://bugzilla.redhat.com/show_bug.cgi?id=1469670
I've been on a code-deleting rampage lately, killing off many minor features that add a lot of complexity for seemingly little gain. Glad I don't have anyone interrogating me like this!
- ape4 3y agoThat was interesting - "Umm, this change causes major slowdowns in various bits of systemd code, which assumes that getpid() is fast. libsystemd uses getpid() to detect when processes fork". A regular userspace program doesn't need to detect when a fork() has occurred since its whats doing the fork().
- deleted 3y ago[deleted]
- senkora 3y agoThe snark here is impressive: > in order to quickly fix this pressing matter, I've attached code that I believe will fix your issue. It uses a custom caching mechanism and fits well into the systemd ecosystem. pid_t systemd_getpid(void) { return 0; }
- fullstop 3y agoIt's kind of a dick answer, imo.
- marcosdumay 3y agoI'm really not sure if it's perfectly context sensitive or too much even for systemd. But dick answers is the specialty of the systemd development team. I wouldn't want to get into a contest against them.
- flakes 3y agoThat one had me laughing really hard haha
- Dwedit 3y agoCaching the result of getpid causes you to need to change the value after it's forked. So fork must be wrapped if getpid is wrapped.