I'm not sure it *does* run.  That is, I don't think a Haskell-based signal handler is even possible.  When I talk about Haskell's signal handlers, I mean C handlers within the GHC runtime.

1.  The GHC runtime only protects garbage collection from signals, it doesn't protect anything else.  In particular, unless memory allocation is somehow atomic, a signal arriving while something is doing an allocation dare not itself do any allocation — which means it can do very nearly nothing.

2.  Registering a Haskell-based signal handler would be a special case of arranging for C to call into Haskell code (since that is in fact what it would be doing; the real signal handler is C invoked from an assembler trampoline).  As things currently work, this can only be done from calls to C which suspend the Haskell runtime in a known safe state; asynchronous signals don't provide any way to arrange this, any more than they insure C's malloc() arena is consistent or etc.

If a Haskell-hosted signal handler mechanism were to be provided, it would have to be done by invoking the handler from the next run of the event loop.  The existing signal handlers work this way already, as I mentioned already; the actual signal handler writes a byte doen a pipe, and the runtime acts on it from its event loop.  This is because there is so little that is safe to do from any signal handler, and even less that is safe within the context of GHC's runtime.