Signal inconsistency between GHC and GHCi

[Simon Marlow]

Sven Panne wrote:
> Am Sonntag, 1. Januar 2006 19:40 schrieb Bulat Ziganshin:
> 
>>Sunday, January 01, 2006, 2:27:01 PM, you wrote:
>>
>>>>>>[ usleep/nanosleep trouble deleted... ]
>>>>
>>>>may be you comile with -threaded? ghci don't use this option, afaik
>>
>>SP> The SIGALRM happen with purely interpreted code and even without
>>loading any SP> code at all into GHCi... :-(
>>
>>i say that your COMPILED code works ok because it uses -threaded, but
>>GHCi fails because it just never use this option
> 
> 
> Well, you can safely assume that I would have mentioned any strange 
> commandline flags used for compilation, so don't jump to wild assumptions... 
> It was plain old "ghc --make Blah.hs" on x86 SuSE Linux. And no, GHCi did not 
> get any options, either.
> 
> Anyway, the question was (slightly reformulated): Why does GHCi seize the 
> SIGALRM resource and why does it receive high-frequency signals even when 
> idling on the prompt? Neither is this very power-saving-friendly nor 
> necessary and can lead to problems with external libraries. Perhaps our RTS 
> Grand Master SimonM can comment on this. :-)

Looking at the code in ghc/rts/posix/Itimer.c (ghc/rts/Itimer.c in STABLE):

#ifdef RTS_SUPPORTS_THREADS
#define ITIMER_FLAVOUR  ITIMER_REAL
#define ITIMER_SIGNAL   SIGALRM
#else
#define ITIMER_FLAVOUR  ITIMER_VIRTUAL
#define ITIMER_SIGNAL   SIGVTALRM
#endif

So the -threaded RTS uses ITIMER_REAL for obscure reasons detailed in
the comment next to that code.

I don't understand why you're seeing a difference with GHCi, unless your
GHCi was somehow compiled with -threaded? (that isn't the default).

If there's a better way to get a timer signal that is transparent to the
running code, I'm all ears.

Cheers,
	Simon