When Multiple Signal Handlers Register, They Step on One another

[sargun]

If you try to register signal handlers multiple times for the same signal, the last one wins. This can lead to undefined behaviour if libraries use signal handlers.

[mfelsche]

Thanks for reporting.
I quickly wanted to check on this and it is true, that only 1 signal handler is called for 1 distinct signal.

Here is a minimal example to show this behaviour:

use "signals"

actor Main
  new create(env: Env) =>
    let handler1 = SignalHandler(
      object iso is SignalNotify
        fun ref apply(count: U32): Bool =>
          env.out.print("1")
          true
      end,
      Sig.usr1()
    )
    let handler2 = SignalHandler(
      object iso is SignalNotify
        fun ref apply(count: U32): Bool =>
          env.out.print("2")
          true
      end,
      Sig.usr1()
    )
    raise()

  be raise() =>
    SignalRaise(Sig.usr1())

The behaviour on how multiple signal handlers for the same signal behave is not documented in the signals sources or docs. If it were, i would say this should be turned into an RFC, allowing multiple signal handlers for the same signal (with undefined order). But as there is no documentation, this could be handled as a principle of least surprise enhancement without RFC. But maybe others have a different opinion on this.

[Praetonus]

After taking a look at the signal implementation (asio/epoll.c and asio/kqueue.c), the behaviour you describe seems to correspond to the OSX implementation. This implementation is, as you point out, not thread safe, and I seem to recall another issue opened about that problem. I can't find it though.

The Linux implementation also has problems, and isn't fully thread safe (though it's better than the OSX implementation). On that platform, the first signal handler registered wins, and cannot be replaced. Every other signal handler created for the same signal will silently do nothing.

In addition, both implementations have a problem with signals like SIGFPE, SIGILL and SIGSEGV (and SIGABRT when raised by abort()), as these signals are required to terminate the program after the signal handler returns. Since our signal handler delegates things to epoll/kqueue, this means that user handlers for these signals won't be called.

The Pony interface in the standard library is problematic as well, as it isn't capability secure. Any function can raise a signal or register a signal handler without first getting the capability to do so.

All in all, I think signals are pretty much broken right now, both from a design and from an implementation standpoint.

Aside from fixing the thread safety issues and the capability security of the interface, I think the questions here are:

• As @mfelsche said, what should the behaviour be when trying to register multiple signal handlers? If we only allow one at a time, the replacement needs to be capability secure (i.e. a function should need something derived from AmbientAuth in order to replace a signal handler).
• What should signal handlers for fatal signals look like? Should we even allow users to handle them?

[SeanTAllen]

Benoit, Are you suggesting that you should be able to register the same signal handler more than once? That's not something that OSX or Linux let's you do. Some signal implementations allow you to chain handlers. Some do not.

…

On Thu, Apr 5, 2018, 4:40 AM Benoit Vey ***@***.***> wrote: After taking a look at the signal implementation (asio/epoll.c and asio/kqueue.c), the behaviour you describe seems to correspond to the OSX implementation. This implementation is, as you point out, not thread safe, and I seem to recall another issue opened about that problem. I can't find it though. The Linux implementation also has problems, and isn't fully thread safe (though it's better than the OSX implementation). On that platform, the *first* signal handler registered wins, and cannot be replaced. Every other signal handler created for the same signal will silently do nothing. In addition, both implementations have a problem with signals like SIGFPE, SIGILL and SIGSEGV (and SIGABRT when raised by abort()), as these signals are required to terminate the program after the signal handler returns. Since our signal handler delegates things to epoll/kqueue, this means that user handlers for these signals won't be called. The Pony interface in the standard library is problematic as well, as it isn't capability secure. Any function can raise a signal or register a signal handler without first getting the capability to do so. All in all, I think signals are pretty much broken right now, both from a design and from an implementation standpoint. Aside from fixing the thread safety issues and the capability security of the interface, I think the questions here are: - As @mfelsche <https://github.com/mfelsche> said, what should the behaviour be when trying to register multiple signal handlers? If we only allow one at a time, the replacement needs to be capability secure (i.e. a function should need something derived from AmbientAuth in order to replace a signal handler). - What should signal handlers for fatal signals look like? Should we even allow users to handle them? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/ponylang/ponyc/issues/2632#issuecomment-378862306>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAL0PEQqZPIuo7mUvDlqx5MnU4Bx_O1_ks5tldh1gaJpZM4TH_fk> .

[Praetonus]

@SeanTAllen It could be handled by the runtime. For example by storing a list of ASIO events for each signal, instead of just one.

[SeanTAllen]

I wouldnt consider what it does now broken, it it what I as someone unfortunate enough to use signals a lot in the past would expect. That said, if we could normalize that, it would be great.

[Praetonus]

The main argument I have for treating this as a bug is that the Linux and OSX implementations currently do opposite things.

[SeanTAllen]

well, Linux and OSX do different things. So I wouldnt call it a bug. But I think that if we can address, that would be a good thing.

[sargun]

@Praetonus I'm somewhat ignorant, since I've only been reading the code for a couple hours, how is the OS X kqueue implementation thread unsafe?

It looks like ponyint_asio_backend_dispatch is executed serially. Is it that pony_asio_event_subscribe has no locking with it and that can create skew?

[mfelsche]

We discussed this during sync and decided to move the discussion about how the signal interface should look like to an RFC ticket.

[Praetonus]

@sargun Sorry, I forgot to reply to you here. I was incorrect, the OSX implementation is indeed thread safe. The other problems are still relevant, though.