#49 Add ABORT restart to threads

closed-fixed
UI (5)
5
2012-09-14
2012-07-19
Anonymous
No

* "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.

Discussion

  • Sam Steingold
    Sam Steingold
    2012-07-19

    • labels: --> UI
    • assigned_to: nobody --> vtz
     
  • 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.

     

  • Anonymous
    2012-07-20

    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.

     
    • status: open --> closed-fixed
     
  • 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.

     

  • Anonymous
    2012-09-14

    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.

     

  • Anonymous
    2012-09-14

    ... 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.)

     

  • Anonymous
    2012-09-15

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