Interrupt key idiocy
Locked
 
|
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; [hidden email]; http://www.rowledge.org/tim Never do at compile-time what you can put off till run-time |
|
|
+1
|
|
|
In reply to this post by timrowledge
Hoi Tim-- > ... > > Whatever the details really are, it would certainly be nice to make > response to the interrupt key *really* fast. It sounds like you have the means to make this so, and I heartily approve! -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
|
|
In reply to this post by timrowledge
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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim > Never do at compile-time what you can put off till run-time > > > |
|
|
On Thu, 6 Mar 2014, Chris Muller wrote:
> 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... In theory the emergency evaluator (Transcripter) will pop up instead of another debugger. See Object >> #primitiveError:. Levente > > On Wed, Mar 5, 2014 at 11:37 PM, tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim >> Never do at compile-time what you can put off till run-time >> >> >> > > |
|
|
In reply to this post by Chris Muller-3
On 06-03-2014, at 8:16 AM, Chris Muller <[hidden email]> wrote: > 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… That’s certainly one kind of problem we can so easily make for ourselves and as Levente points out it *should* trigger the emergence evaluator. On a good day, at least. I suppose at some point I (and by ‘I’, I mean possibly me or perhaps some other person with some actual available time, if such a person exists) should probably add some debug code to trap the time the cmd-. was actually pressed, the time when it was recognised in either EventSensor>processEvent: or the InputSensor>userInterruptWatcher etc. My suspicion is that the interrupt is not getting into the image in a timely manner but it could of course be some problem in the work to actually open the debugger once the interrupt has been handled. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Understands English as well as any parrot. |
|
|
I have not checked this in a while (and cannot do so right now), but
Andreas provided four tests that should be expected to be interruptable (on any VM in both Morphic and MVC). These are: * "[true] whileTrue" * "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1" * "Smalltalk createStackOverflow" * "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1" There are a number of Mantis entries that provide background and descriptions of unsolved problems. They are collected in Mantis 7655: "A mother for user interupt bugs and problems" http://bugs.squeak.org/view.php?id=7655 Dave > > On 06-03-2014, at 8:16 AM, Chris Muller <[hidden email]> wrote: > >> 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 > > Thats certainly one kind of problem we can so easily make for ourselves > and as Levente points out it *should* trigger the emergence evaluator. On > a good day, at least. > > I suppose at some point I (and by I, I mean possibly me or perhaps some > other person with some actual available time, if such a person exists) > should probably add some debug code to trap the time the cmd-. was > actually pressed, the time when it was recognised in either > EventSensor>processEvent: or the InputSensor>userInterruptWatcher etc. My > suspicion is that the interrupt is not getting into the image in a timely > manner but it could of course be some problem in the work to actually open > the debugger once the interrupt has been handled. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Useful random insult:- Understands English as well as any parrot. > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |