[squeak-dev] Interrupt key idiocy

Chris Muller asqueaker at gmail.com
Thu Mar 6 16:16:02 UTC 2014


If, during the act of building and opening the debugger, if something
causes yet another exception to be triggered (say, a bad printOn: or
problem building one of the inspector panes), then I think you'll be
in an unavoidable infinite recursion.  Not sure whether there's any
way around that...

On Wed, Mar 5, 2014 at 11:37 PM, tim Rowledge <tim at rowledge.org> wrote:
> 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