3 ms·

On Linux you got signalfd and on BSDs you got kqueue. It is only difficult if you are avoiding the tools made specifically to address the problem.

by zokier 2y ago

crest 2y ago
On FreeBSD you also have process descriptors (Linux followed suite a while ago) which provide a race free clean interface to supervise processes even if you're not their reaper (so can't use PIDs reliably). You can add them to kqueue using the EVFILT_PROCDESC filter with the NOTE_EXIT flag to get notified when the referenced process exits. The exit status you would normally get from waitpid() is already in the struct kevent. These OS specific APIs are sometimes required and may make certain usecases a lot easier to implement correctly (or even at all), but a job server for a build system isn't one of those. The make jobs can be required to behave and stay in the process group the job server creates for them just like shell job control. Which can be done with just POSIX API. You just have to blow the dust from the relevant tombs the ancients left us (e.g. Advanced Programming in the UNIX Environment). Refuse the temptation and don't make infrastructure tools like gmake depend OS specific APIs. Doing so would make the world a worse place for everyone else.
- o11c 2y ago
  PIDs are always reliable for your own direct children.
- danudey 2y ago
  > don't make infrastructure tools like gmake depend OS specific APIs Even if you're going to implement OS-specific APIs you still need a general case for OSes that don't support those APIs or don't support them correctly. That means you still need to solve the original problem regardless, which then means that it doesn't actually save you time and energy to use those APIs but rather creates more development and maintenance work and not less. If those APIs don't provide you a significant benefit (reliability, performance, etc.) then it's likely not worth implementing them at all if the general case works, and if it doesn't work you have to fix it anyway.
- zokier 2y ago
  > Refuse the temptation and don't make infrastructure tools like gmake depend OS specific APIs. Doing so would make the world a worse place for everyone else. Make is supposed to be the interface, implementations should be able to leverage all the platform capabilities they need, because make is part of that platform. Forcing lowest common denominator also makes world worse place, as does relying on single specific implementation.
cesarb 2y ago
> On Linux you got signalfd AFAIK, make's jobserver protocol is much older than signalfd.
Karellen 2y ago
Although the HN title says (2015), at the top of the article is: > June 16th, 2003 (updated September 26th, 2015) so when it was originally written signalfd(2) would not be available on Linux until 2.6.22 was released in July 2007, 4 years later.

On Linux you got signalfd and on BSDs you got kqueue. It is only difficult if you are avoiding the tools made specifically to address the problem.

by zokier 2y ago

On Linux you got signalfd and on BSDs you got kqueue. It is only difficult if you are avoiding the tools made specifically to address the problem.

crest 2y ago

On FreeBSD you also have process descriptors (Linux followed suite a while ago) which provide a race free clean interface to supervise processes even if you're not their reaper (so can't use PIDs reliably). You can add them to kqueue using the EVFILT_PROCDESC filter with the NOTE_EXIT flag to get notified when the referenced process exits. The exit status you would normally get from waitpid() is already in the struct kevent. These OS specific APIs are sometimes required and may make certain usecases a lot easier to implement correctly (or even at all), but a job server for a build system isn't one of those. The make jobs can be required to behave and stay in the process group the job server creates for them just like shell job control. Which can be done with just POSIX API. You just have to blow the dust from the relevant tombs the ancients left us (e.g. Advanced Programming in the UNIX Environment). Refuse the temptation and don't make infrastructure tools like gmake depend OS specific APIs. Doing so would make the world a worse place for everyone else.

o11c 2y ago
PIDs are always reliable for your own direct children.
danudey 2y ago
> don't make infrastructure tools like gmake depend OS specific APIs Even if you're going to implement OS-specific APIs you still need a general case for OSes that don't support those APIs or don't support them correctly. That means you still need to solve the original problem regardless, which then means that it doesn't actually save you time and energy to use those APIs but rather creates more development and maintenance work and not less. If those APIs don't provide you a significant benefit (reliability, performance, etc.) then it's likely not worth implementing them at all if the general case works, and if it doesn't work you have to fix it anyway.
zokier 2y ago
> Refuse the temptation and don't make infrastructure tools like gmake depend OS specific APIs. Doing so would make the world a worse place for everyone else. Make is supposed to be the interface, implementations should be able to leverage all the platform capabilities they need, because make is part of that platform. Forcing lowest common denominator also makes world worse place, as does relying on single specific implementation.

cesarb 2y ago

> On Linux you got signalfd AFAIK, make's jobserver protocol is much older than signalfd.

Karellen 2y ago

Although the HN title says (2015), at the top of the article is: > June 16th, 2003 (updated September 26th, 2015) so when it was originally written signalfd(2) would not be available on Linux until 2.6.22 was released in July 2007, 4 years later.