[squeak-dev] Interrupt key idiocy

tim Rowledge tim at rowledge.org
Thu Mar 6 05:37:46 UTC 2014


Y’know what is still annoying the hell out of me when developing? The damn interrupt key stuff. I’ll leave aside the problem with not necessarily interrupting the ‘right’ process, because I know that is really quite difficult. 

But the spec we agreed something like a decade (or more) ago was that the interrupt key combo, when pressed, would NOT be passed into the image but would immediately trigger the relevant semaphore. That should open a debugger pretty lickety-split. It doesn’t seem to work that way any more, with frequent cases where nothing happens for a very long time, often long enough that you simply give up and force-quit. I *think* this is often in a deep recursion scenario, which I understand can be a problem for collecting all the contexts.

I know it worked very well on RISC OS. It doesn’t appear to be doing very well on OS X nor linux/Pi.  So, I have to admit I’m a bit puzzled to see image code (in EventSensor>processEvent:) that purports to handle the interrupt key code that is supposed never to get there. The comment in the related code in InputSensor>primInterruptSemaphore: explicitly refers to the setting of the semaphore for the VM as obsolete, though it does at least actually set it. So far as I can see the prim exists and does the right thing. The only material difference I can find between platforms is that RISC OS does
  setInterruptPending(true);
  forceInterruptCheck();
whereas all others do just
  setInterruptPending(true);
and perhaps that makes a big difference.

Event handling code in the relevant platform files also appears to explicitly *not* pass in a cmd-. key-press which confuses me further, since that makes it seem like the system is actually relying upon the semaphore being signalled by the VM despite the image code. 

Whatever the details really are, it would certainly be nice to make response to the interrupt key *really* fast.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Never do at  compile-time what you can put off till run-time




More information about the Squeak-dev mailing list