2009/12/3 Lars Rune Nøstdal <larsnostdal@...>:
> Renaming the `terminate-thread' restart to `abort' makes things
> easier/faster when dealing with run-away threads. E.g., with this
> change I can hit the Q key in Slime and have the thread instantly
> killed instead of having to "manually" search through perhaps 20 or so
> restarts that all are futile anyway before finding the one I was
> looking for to begin with; `terminate-thread', which has no shortcut
> key bound to it.
I'm of two minds about this. On the one had that would seem a very
drastic interpretation of ABORT: if you read the spec, the intent is
to return to the innermost command level. So for example, in Ltk we
have a restart named ABORT which unwinds back to the main loop, and
goes back to waiting for the next Tk event. We have a different EXIT
restart, which terminates the Tk application.
On the other hand, implementors are enouraged to always ensure that
there is an ABORT restart present. Restarting the thread would be
stranger than terminating it is drastic, and if the thread enters any
kind of reasonable event loop, there ought to be another ABORT that
shadows the terminate-thread one.
So I'm ambivalent, though leaning towards favorable, but not for the
reasons you argue :-)
> I'm not sure if this will work well in all cases, and perhaps it is a
> better idea to just add (instead of doing a rename) an `abort' restart
> in case users already depend on the `terminate-thread' restart being
I'm not sure what you mean by "will work well in all cases," but if
you mean that ABORT will reliably terminate threads after that change,
no, not if that thread is running an Ltk program, for example :-)
On the one hand, it's not documented as a restart ... on the other
hand, it is documented as a function which is part of the API, so it
looks like something that can be relied on.
> This is sort of a user interface type of thing, so perhaps it is
> instead Slime that should adapt in some way by adding a shortcut key
> for termination of threads now that the various Lisps have threading?
> ..or perhaps it should just fall back to the `terminate-thread'
> restart when Q is hit and no `abort' restart was found. I don't know
> -- thoughts?
If Slime does not in fact have an easy way to terminate a thread
(although I thought there was a key binding for that in the
list-threads buffer), I think it would be a good idea for it to grow
one. SBCL already provides a perfectly fine API for doing so.