Bug tracking notes:
I have added Andreas' note below to Mantis 7656. Mantis 7656: User interrupts key does not always work the first time it is pressed.
The parent Mantis issue for several related issues is http://bugs.squeak.org/view.php?id=7655 Mantis 7655: A mother for user interupt bugs and problems
Background on the underlying signaling mechanism (not directly related to the current discussion but worth knowing) is Mantis 1041: [VM][ENH] LowSpaceAndInterruptHandler-dtl
This one is still open but should probably be closed as a "will not fix" Mantis 4818: [KernelImageOverride] InputSensor userInterruptWatcher
Dave
On Fri, Dec 16, 2011 at 08:00:03AM +0100, Andreas Raab wrote:
On 12/16/2011 3:33, Levente Uzonyi wrote:
On Thu, 15 Dec 2011, Christopher Oliver wrote:
On Thu, 15 Dec 2011 11:35:55 +0100 I added a tty output debug to MorphicProject>>interruptName:preemptedProcess:, and I found that Processor>>preemptedProcess occasionally answers the system weak array finalization process. Yikes! This isn't what we want to debug at all. Are we being adequately clever in determining which process to debug?
I'm pretty sure that the currently running process is interrupted. After GC (which happens often during calculations with LargeIntegers) this is likely to be the finalization process.
Correct. To make matters worse, when an interrupt is signaled in the midst of GC, the signal will be delivered after the GC cycle completes, therefore almost guaranteeing that the interrupted process will be the finalization process.
And so the determination of the process to be interrupted is moderately stupid. What we'd really need to do is to start a slightly leaner version of CPUWatcher, i.e., instead of blindly interrupting whatever process is active, start sampling the running processes and after a short while (100-500 ms) decide which process to kick[*]. Plus, after that ensure that the UI is actually responsive so that the user can interact with the system and if not, keep kicking processes unless the system becomes interactive again. Alas, not a trivial task to be solved.
[*] A more radical version would suspend *all* user processes and let the user decide which of the suspended processes to inspect. This might have some interesting side effects though...
Cheers,
- Andreas