Hacker News Reader

Comment by pjc50 | Hacker News Reader

> which had a tight loop to detect when a process was forked.

This sounds so mad it needs more context. You don't need to detect when a process is forked, it's an action issued from inside the process?

View on HN

Maybe the problem is that it is "lib"systemd, meaning it doesn't really have control over when the process forks, it's the application code's responsibility. Although I would probably also avoid this design, but that would probably make the library interface a bit unfriendly, with the application needing to pass its own pid to library functions where appropriate.

The audacity of the design to detect a pid change by looking at it in a loop, is interesting. I don't think I could have come up with something like that. Feels very "sync the web DOM by traversing it and comparing with a shadow DOM".

If only we had an API to tell us when a fork happened. We could place it into the usual library for threading stuff: pthread, and could call it, oh I don't know, maybe pthread_atfork()

https://man7.org/linux/man-pages/man3/pthread_atfork.3.html

It is mentioned in the glibc bug tracker entry as a replacement to the polling. systemd didn't use it because they thought it would be impossible for a library using to be dlclose'd as there is no way to unregister the callback. But apparently glibc has (undocumented) magic under the hood to take care of it.

Reply on news.ycombinator.com