[ clisp-Feature Requests-3545986 ] Add ABORT restart to threads

Feature Requests item #3545986, was opened at 2012-07-19 11:03
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: UI
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Add ABORT restart to threads

Initial Comment:
* "Implementors are encouraged to make sure that there is always a restart named abort around any user code so that user code can call abort at any time ... in some batch or multi-processing situations there may be situations in which having it kill the running process is more appropriate." http://clhs.lisp.se/Body/r_abort.htm

* There's nothing to do inside the debugger with no restarts; the 'a' key in SLIME doesn't work.

* Since bordeaux-threads does not permit a thread to kill itself, there is no implementation-neutral way of self-terminating a thread outside of invoking ABORT (or establishing some other restart beforehand).

* User code which has already added an ABORT restart is OK, since the user's ABORT will hide the new topmost ABORT.

* Peer pressure: these implementations define ABORT inside threads: ABCL, Allegro, Clozure, ECL, LispWorks, SBCL.

----------------------------------------------------------------------

Comment By: lmj ()
Date: 2012-09-14 20:30

Message:
Oh, thread_interrupt pops the stack when called with the current thread.
Nevermind.

----------------------------------------------------------------------

Comment By: lmj ()
Date: 2012-09-14 15:45

Message:
... I mean using RESTART-CASE or equivalent to unwind; THREAD-INTERRUPT
seems to be overkill. (It wouldn't be sufficent to set :INVOKE-FUNCTION to
an empty lambda.)

----------------------------------------------------------------------

Comment By: lmj ()
Date: 2012-09-14 15:26

Message:
Why does the :INVOKE-FUNCTION call THREAD-INTERRUPT? Isn't it sufficient to
do nothing? Execution will then reach the end of the thread function, and
the thread is done.

----------------------------------------------------------------------

Comment By: Vladimir Tzankov (vtz)
Date: 2012-09-14 13:20

Message:
Thanks for the suggestion - it has been just implemented and
checked into the CVS repository, and will be available in the next
release.
If you cannot wait for the next release, you can get the latest
development sources from the CVS and compile them yourself.
Please be aware that the development sources are not stable and
might not even compile on your machine.
You should report any problems you encounter with the CVS sources
to the <clisp-devel> mailing list, not to the <clisp-list>.
If you use the CVS sources, you should read <clisp-devel>
since the CVS log goes there.

----------------------------------------------------------------------

Comment By: lmj ()
Date: 2012-07-20 05:03

Message:
I'm not sure I understand your point. The standard draws a distinction
between a REPL process and other processes.

"Typically, in an interactive listener, the invocation of abort returns to
the Lisp reader phase of the Lisp read-eval-print loop, though in some
batch or multi-processing situations there may be situations in which
having it kill the running process is more appropriate."
http://clhs.lisp.se/Body/r_abort.htm

So the main REPL thread is already doing what the standard suggests.

----------------------------------------------------------------------

Comment By: Vladimir Tzankov (vtz)
Date: 2012-07-20 03:28

Message:
Currently we throw special tag in the context of the thread in order to
cause it to exit - I can replace this with abort restart.
However what to do with the "main" thread - should we do the same? It is
not good to treat it specially.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

------------------------------------------------------------------------------
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel