Thanks Evan. Am 18.01.2016 um 03:59 schrieb Evan Hanson: > 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.
So be it. I'm not the native English speaker to eventually judge. >> 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. Not per Unix specification. But according to my knowledge implementations usually do this trick. (But maybe my knowledge is a bit outdated? Is this text just too old:) http://www.tldp.org/LDP/tlk/ipc/ipc.html """Signals are not presented to the process immediately they are generated., they must wait until the process is running again. Every time a process exits from a system call its signal and blocked fields are checked and, if there are any unblocked signals, they can now be delivered.""" > 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 OK, I did not check that one. Cheers /Jörg _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers