Signal inconsistency between GHC and GHCi

Simon Marlow simonmar at microsoft.com
Tue Jan 10 07:59:04 EST 2006


Simon Marlow wrote:
> 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).

I lied, GHCi was compiled with -threaded, until I turned it off a few 
days ago.

However, this is a general problem - the use of SIGALRM, and indeed 
SIGVTARLM could potentially conflict with the user program.  We should 
perhaps be using timer_create() or something.

Cheers,
	Simon




More information about the Glasgow-haskell-bugs mailing list