#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
     
  • Vladimir Tzankov

    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.

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    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.

     
  • Vladimir Tzankov

    • status: open --> closed-fixed
     
  • Vladimir Tzankov

    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 has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    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.

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

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

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-09-15

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

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks