chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] Scheduler fdset assert patch


From: Jonathan Chan
Subject: Re: [Chicken-hackers] Scheduler fdset assert patch
Date: Wed, 15 Jul 2015 18:32:49 -0400

Hello all,
 
Here is yet another version of the patch, with fixes pointed out by Peter on IRC (thanks! :). The hide declaration in scheduler.scm is fixed, and signal-tests is patched so that a flag set by a signal handler that was previously a parameter is changed to be a global variable. This doesn't work with the patched scheduler because parameters are thread-local and the patched scheduler explicitly run the signal handler in a new thread (to avoid the scheduler assert bug, etc.)
 
This worked in the past simply because when the signal hook ran the signal handler it would do so on whatever thread happened to have its state set at the time. Because signal-tests.scm did not start any threads, there was therefore only one thread that the signal handler could run on, so it acted *as if* it were run on the same thread and therefore had access to the same parameter. As far as I can tell, this is actually relying on undefined behavior, because the documentation for set-signal-handler! says that it's unspecified on which thread the handler will be invoked and parameters are thread-local (and this is in fact non-deterministic, so programs with more than one thread that relied on the signal handler running on a certain thread would have probably run into problems already).
 
Peter pointed out that the patch might break existing programs, as is the case for signal-tests. I think that this should only happen, however, in very edge cases. Specifically, the program has to have only one thread, and it has to rely on the signal handler being run in the same thread, e.g. by setting parameters in the signal handler and expecting the changes to be visible from the main thread. I believe that nearly all programs that currently work using signal handlers should continue to function the same. I agree that the potential incompatibility could be a problem, though, so if anyone else has programs that might exhibit this behavior and could test them that would be great.
 
Of course, as always, if anyone can look over or test this patch that would be very much appreciated!
 
Best regards,
--
Jonathan Chan
address@hidden

Attachment: scheduler-interrupts-complete-6.diff
Description: Binary data


reply via email to

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