chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] chicken interupt handling


From: Jörg F . Wittenberger
Subject: [Chicken-users] chicken interupt handling
Date: 04 Sep 2011 12:21:22 +0200

Hi (Felix ;-),

I wonder if there is a bug in the runtime.c concerning interrupt handling.

But I don't understand the code enough.

C_raise_interrupt will do
C_regparm void C_fcall C_raise_interrupt(int reason)
{
 if(C_interrupts_enabled) {
   saved_stack_limit = C_stack_limit;

#if C_STACK_GROWS_DOWNWARD
   C_stack_limit = C_stack_pointer + 1000;
#else
   C_stack_limit = C_stack_pointer - 1000;
#endif

   interrupt_reason = reason;
   interrupt_time = C_cpu_milliseconds();
 }
}

But there's already my first suspect: C_cpu_milliseconds boild down to
a system call, which AFAIK could dispatch the next signal already.

But things *seem* to get even worse: If I read the source right, then
C_context_switch must be used to complete the handle_interrupt.  Correct?
And this too will (seems to) change global state wrt. stack pointers.

Hence I'd say: any interrupt signal coming in between the initial
C_raise_int and C_context_switch is potential harmful.

At least I can not explain to myself, why the code would work for sure.

After having played with several variations of signal delivery, all
ending up in a tight loop sooner or later, I got the idea to add
one more variable (puh): a flag being set to true at the bottom of
C_context_switch (right before the trampoline call
and set to 0 before the global_signal_handler calls C_raise_interrupt.
Also C_raise_interrupt is only called if the flag was at 1, thus
at most once per C_context_switch.

While all those other experiments mitigated the issue at best, this
one appears to work for hours.  At least things ran over night.

Best regards

/Jerry
..........



reply via email to

[Prev in Thread] Current Thread [Next in Thread]