Custom user Interrupt handling

For the GLASS GemTools client, I would like to intercept Alt-. and instead of opening a debugger, I would like to send an interrupt to the GemStone process.

In Squeak and earlier variants of Pharo, it was possible to replace the interruptSemaphore with one of our own while we were waiting and it worked well enough.

With the new structure of InputSensor and friends it doesn't appear to be possible to hack into the event handling system for user interrupts.

The class UserInterruptHandler is tantalizingly close, however, there is no obvious way to insinuate myself as an interested party....It's pretty much hard-wired to open a debugger on the interrupted process....

There are probably several ways to allow for the user interrupt to be intercepted:

  - use a dynamic variable
  - use a process local

Both techniques have the advantage of being process specific...

On the other hand if it is easier/preferable to use Ctl-ALT-. then that would work for me.

Thanks in advance,

Dale

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

It looks as though using signalException:, and a UserInterrupt notification whose defaultAction is to open the debugger will do the trick ... An exception handler on the stack for UserInterrupt can intercept the interrupt and do something different than opening a debugger.

I've attached two fileIns with an example implementation...a quick review by a knowledgeable soul would be appreciated (not much code involved at all).

If there aren't any other alternatives and this approach is deemed to be acceptable, I can go through the standard process and submit a bug/bugfix (bullet-proofing the code a bit as well).

Dale
----- "Dale Henrichs" <[hidden email]> wrote:

| For the GLASS GemTools client, I would like to intercept Alt-. and
| instead of opening a debugger, I would like to send an interrupt to
| the GemStone process.
|
| In Squeak and earlier variants of Pharo, it was possible to replace
| the interruptSemaphore with one of our own while we were waiting and
| it worked well enough.
|
| With the new structure of InputSensor and friends it doesn't appear to
| be possible to hack into the event handling system for user
| interrupts.
|
| The class UserInterruptHandler is tantalizingly close, however, there
| is no obvious way to insinuate myself as an interested party....It's
| pretty much hard-wired to open a debugger on the interrupted
| process....
|
| There are probably several ways to allow for the user interrupt to be
| intercepted:
|
|   - use a dynamic variable
|   - use a process local
|
| Both techniques have the advantage of being process specific...
|
| On the other hand if it is easier/preferable to use Ctl-ALT-. then
| that would work for me.
|
| Thanks in advance,
|
| Dale
|
| _______________________________________________
| Pharo-project mailing list
| [hidden email]
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dale Henrichs wrote:

> The class UserInterruptHandler is tantalizingly close, however, there
> is no obvious way to insinuate myself as an interested party....It's
> pretty much hard-wired to open a debugger on the interrupted
> process....

Just write your own class (e.g. subclass UserInterruptHandler) and
replace the handler (unregister the current one and register your own).

That's why I designed it the way it is :-)

michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Michael,

Thanks! Subclassing it is.

Dale

----- "Michael Rueger" <[hidden email]> wrote:

| Dale Henrichs wrote:
|
| > The class UserInterruptHandler is tantalizingly close, however,
| there
| > is no obvious way to insinuate myself as an interested
| party....It's
| > pretty much hard-wired to open a debugger on the interrupted
| > process....
|
| Just write your own class (e.g. subclass UserInterruptHandler) and
| replace the handler (unregister the current one and register your
| own).
|
| That's why I designed it the way it is :-)
|
| michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Michael,

What's the approved method for unregistering the current user interrupt handler?

  InputEventFetcher default eventHandlers copy do: [:hndlr |
    (hndlr isKindOf: UserInterruptHandler) ifTrue: [ hndlr unregister]].

Looks like it would work, but seems a bit fragile.

Dale

----- "Michael Rueger" <[hidden email]> wrote:

| Dale Henrichs wrote:
|
| > The class UserInterruptHandler is tantalizingly close, however,
| there
| > is no obvious way to insinuate myself as an interested
| party....It's
| > pretty much hard-wired to open a debugger on the interrupted
| > process....
|
| Just write your own class (e.g. subclass UserInterruptHandler) and
| replace the handler (unregister the current one and register your
| own).
|
| That's why I designed it the way it is :-)
|
| michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hello all,

This reminds me of some things that evolved in Dolphin, at least some of which Pharo has already.

Logging of unhandled exceptions is important, and Pharo does it.  However, it appears to replace debug.log with every error.  There should be an easy way to get it to accumulate errors.  Imagine monitoring the performance of a server or embedded system; one cares not only that a backup or update failed, but that it fails often, etc.  The log needs to be thread safe.

Much of the content of debug.log looks like it overlaps with what Dolphin puts in a "crash dump."  IIRC, it was my idealism combined with Blair McGlashan's deep understanding of VMs that lead to the latter.  I noted that unhandled Smalltalk exceptions were logged, but the more rare crash that made it all the way to the OS was completely silent in the logs.  Blair created the dump and added an interesting twist, which was to allow a crash dump to be fired off without actually needing the crash.  That meant that the detailed (and verbose) stack dump with data was created on a crash, and could be triggered as needed.  The error log did not carry the additional data, and was therefore small enough to accumulate.

Chris Uppal created a wonderful tool called Ghoul to display crash dumps in a debugger-like view.  It shows code from the current image (which might differ from the code that created the dump - but that's life), and inspects data from the dump.  Highly recommended!  There were some snags with format changes over time.  Some of it involved decimal/hex confusion over offsets written by the VM, and possibly spotting the beginning and end of individual dump records.  BTW, the latter problem might be something that I am recalling from my own logging adventures; certainly I had that problem at times, but Ghoul might have too.  I'm not sure, but will mention it to be one the safe side.

Finally, I noted that while there was a way to break out of a hang in the IDE, there was no way to get information from a deployed executable that managed to hang.  I modified my runtime session managers [*]to hook into control-break, and logged text-only stack traces on all non-dead processes.  That allowed me to see deadlocks that showed up rarely.  I have not looked in a while, but the pieces of doing the same thing in Squeak/Pharo exist, perhaps with some cosmetic defects in the spacing between callstacks.  The default "show me the callstack" should dump all stacks, not just the active process.

FWIW.

Bill


[*] session managers are those wonderful Dolphin concepts that allow a Smalltalk image to know when it's been loaded, letting it (among other things) initialize sockets on its own, etc.  Lesser artist borrow, great artists steal - sorry, I'll try to stop nagging :)



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Rueger
Sent: Saturday, August 01, 2009 8:37 AM
To: [hidden email]; [hidden email]
Subject: Re: [Pharo-project] Custom user Interrupt handling

Dale Henrichs wrote:

> The class UserInterruptHandler is tantalizingly close, however, there
> is no obvious way to insinuate myself as an interested party....It's
> pretty much hard-wired to open a debugger on the interrupted
> process....

Just write your own class (e.g. subclass UserInterruptHandler) and replace the handler (unregister the current one and register your own).

That's why I designed it the way it is :-)

michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dale Henrichs wrote:
> Michael,
>
> What's the approved method for unregistering the current user interrupt handler?
>
>   InputEventFetcher default eventHandlers copy do: [:hndlr |
>     (hndlr isKindOf: UserInterruptHandler) ifTrue: [ hndlr unregister]].
>
> Looks like it would work, but seems a bit fragile.

Hmm, well, that part obviously wasn't thought out well...
So your code above would do for now. A better way could be to have the
UserInterruptHandler class remember the current registered handler.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

mike can you add a bugtrack entry for 1.1 on that topic?

On Aug 2, 2009, at 12:42 AM, Michael Rueger wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project