Re: [Chicken-users] chicken interupt handling

[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.

Yes, that may be a problem.

> 
> 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.

Still, even with repeated interrupts, the stack-pointer should still
be beyond the limit, so that a GC is triggered in any case.

> 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.

I see - but the signals coming in while this flag is zero will be
ignored, right?


cheers,
felix