On Mon, Nov 12, 2018 at 2:51 PM, Joseph Myers <joseph@xxxxxxxxxxxxxxxx> wrote: > I see no obvious reason why a kernel-provided > library, with all the problems that entails, should need to be involved, > rather than putting new APIs either in libc I initially wanted to put the APIs in libc. I still do. But that's proving to be impractical, for the reasons we're discussing on this thread. > or in a completely separate > libsignal A separate library can't prevent some use of sigaction elsewhere in the program stomping on its handler. One of the key aspects of the registered-handler design is that registered handlers get to run *before* the legacy process-wide handler. The only non-hacky way to do that is to put the signal handler registration logic in the same logic component that houses the legacy signal registration machinery. > (I can imagine *other* parts of the toolchain being involved, if e.g. you > want to have a good way of checking "is the address of the instruction > causing this signal in this library?" that works with static as well as > dynamic linking - for dynamic linking, I expect something could be done > using libc_nonshared and __dso_handle to identify code in the library > calling some registering function. And indeed there might also be new > kernel interfaces that help improve signal handling.) Again: you're blocking a practical solution for the sake of some elegant theoretical implementation that will never arrive, and so the world remains in a poor state indefinitely. Incremental improvement is good. Nothing about the registered signal handler approach precludes this sort of enhancement in the future. The same goes for the system call metadata database you've described: nice-to-have; shouldn't block simpler and more immediately practical work. > In the absence of consensus for adding such a new API for signals to > glibc, it's unlikely one would get consensus for glibc to depend on some > other library providing such an API either. glibc would continue using an unsupported legacy system call interfaces in lieu of a supported low-level interface library?
