[Ecls-list] Poll: ABORT restart does not exist inside threads

[Juan Jose Garcia-Ripoll]

Could you guys please emit your opinion about this request? How do other
implementations behave in this respect? Do they all offer an ABORT restart
on every thread?

Juanjo

---------- Forwarded message ----------
From: SourceForge.net <noreply at sourceforge.net>
Date: Mon, Jul 2, 2012 at 3:27 PM
Subject: [ ecls-Bugs-3539184 ] ABORT restart does not exist inside threads
To: "SourceForge.net" <noreply at sourceforge.net>


Bugs item #3539184, was opened at 2012-06-30 11:52
Message generated for change (Comment added) made by jjgarcia
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=398053&aid=3539184&group_id=30035

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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: James M. Lawrence ()
Assigned to: Nobody/Anonymous (nobody)
Summary: ABORT restart does not exist inside threads

Initial Comment:
(mp:process-run-function "test" #'abort)

=> Restart ABORT is not active.
   [Condition of type SI::SIMPLE-CONTROL-ERROR]

(let ((out *standard-output*))
  (mp:process-run-function
   "test"
   (lambda ()
     (print (mapcar #'restart-name (compute-restarts)) out))))

=> NIL

Linux xi 3.2.0-24-generic-pae #39-Ubuntu SMP Mon May 21 18:54:21 UTC 2012
i686 i686 i386 GNU/Linux

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

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

>Comment By: Juan Jose Garcia Ripoll (jjgarcia)
Date: 2012-07-02 06:27

Message:
Hi James I am not denying anything a priori. I just have concerns about the
interference between an addition of an ABORT restart for _every_ thread,
and user-defined code that defines their own restarts. As far as I always
read http://clhs.lisp.se/Body/r_abort.htm the text "innermost ``command
level.'" always resounded to me to refer to the Common Lisp toplevel
(interactive read-execute loop). Threads do not have a toplevel processor
and hence ECL does not set up such a restart. However, if all other
implementations set them up, I have nothing against it. I must consult in
the mailing list, because this is a feature change, not a fix.

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

Comment By: James M. Lawrence ()
Date: 2012-07-01 15:14

Message:
I had not considered that you were not intending to add an abort restart.
The standard says that "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..."

So while it is only an "encouragement", an abort restart is present in all
implementations I have tested against except ECL. It seems only natural to
allow users to abort a calculation. What are they supposed to do inside the
debugger with no restarts, not even abort? In bordeaux-threads killing the
current thread is not permitted.

The lack of abort is not ultimately a problem for me, just unfortunate. I
have to disable some tests for ECL or compensate with workarounds. And it
is jarring that the 'a' key doesn't work in SLIME, though with motivation
that could be worked around as well.

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

Comment By: Juan Jose Garcia Ripoll (jjgarcia)
Date: 2012-06-30 13:01

Message:
There is nothing in the specification that states an ABORT restart should
be set up on every image. Why do you consider this an error?

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

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=398053&aid=3539184&group_id=30035



-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20120702/eaf5b875/attachment.html>