[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any
From: |
Evan Hanson |
Subject: |
Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any thread. |
Date: |
Mon, 18 Jan 2016 15:59:55 +1300 |
On 2016-01-15 11:31, Jörg F. Wittenberger wrote:
> I would not be surprised if an innocent reader would read the code
> with the comment missing and conclude that we save the local variable
> `stack_limit` and simply assign C_stack_limit to `saved_stack_limit`,
> which would bring the bug back.
There are no innocent readers of CHICKEN's sources.
More seriously, I think the current text is fine as it clearly explains
the reason for the assignment.
> However - please correct me if I'm wrong at that - C_cpu_milliseconds
> will result in yet another system call. Thus another signal may be
> dispatched at this point. And since `pending_interrupts_count` is still
> zero the first branch of the if statement would be executed again.
To my knowledge the execution of a system call has no bearing on whether
a program is liable to receive a signal at a given point, though I may
certainly be wrong about that.
In any case, the proper way to avoid this situation is to block other
signals from arriving during a handler's execution, which CHICKEN
already does when installing the global signal handler. That's what I
meant when I said nothing would change in the single-threaded case:
another signal won't be dispatched at this point but rather queued until
the first handler returns, so there's no race.
> Still I'd like to learn which memory barrier I should prefer.
NFI, sorry. Any of them will probably turn into an #ifdef soup in short
order.
Evan