Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock

[Baughn]

The runtime system's deadlock detection, being a debugging feature, rightly doesn't break a deadlock if there's any chance a signal will do so later. However, if the only installed signal is XCPU - cpu time-limit exceeded - then that will almost never happen in practice; any program that does want to wait for it will be waiting quite literally years.

As such, it seems best if XCPU is left out of the signal-detection logic. The attached patch does this.

[igloo]

Thanks for the suggestion, and patch! It feels a little ad-hoc to me, and some applications may use the signal for other purposes; any other opinions?

[Baughn]

You are quite right. This patch fixes the immediate problem caused by another patch to lambdabot (that still hasn't been applied) removing loop detection in this specific instance, but a more discriminating system could be helpful.

How about if I write a patch adding an explicit mask/unmask call for this?

[simonmar]

I think this needs to be under programmer control if we do it at all.

Also, the patch doesn't affect the behaviour of the threaded RTS, we should make sure the two behave consistently.