Fix signal handler

[elfring]

I find the use of the variable "SubprocessSet::interrupted_" questionable because of the data type "bool". I recommend to change its data type to "sig_atomic_t".

I suggest also to reconsider the implementation detail about the use of "SetInterruptedFlag" and "NotifyInterrupted" as static member functions for the intended purpose. Does the class "SubprocessSet" need a different design for portable signal handling?

[jhasse]

Too many unanswered questions.

[elfring]

Would you like to consider other software design options?

• sigwaitinfo()
• Self-pipe trick

[jhasse]

I'm not sure what the issue is exactly?

[elfring]

Do you understand the initial clarification request?

[jhasse]

Yeah somewhat. Are we talking about a theoretical problem though or a bug that manifests in the wild because of this?

[jhasse]

If someone wants to fix this, feel free to open a PR. But it looks like a theoretical problem to me, so I'll close this for now.

[elfring]

💭 Would more developers become interested to use a development tool like “clang-tidy” for corresponding source code adjustments?

[jhasse]

We're using clang-tidy already :)

[elfring]

Do such source code analysis tools point any remaining issues out for further development considerations? 🤔

[jhasse]

We only have a few checks enabled: https://github.com/ninja-build/ninja/blob/master/.clang-tidy
See for example this PR which fixes a check and adds it to the configuration so that we don't regress: #1790

clang-tidy output can be seen here under "clang-tidy": https://github.com/ninja-build/ninja/actions/runs/8658203304/job/23741633637

[elfring]

We only have a few checks enabled

🔮 Will the support grow for any more adjustment opportunities (besides readability items)?