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