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