Re: [armedbear-devel] [armedbear-ticket] [armedbear] #164: Cannot quit SLIME REPL
On 22 August 2011 12:21, armedbear <armedbear-devel@common-lisp.net> wrote:
Further analysis reveals that ProcessingTerminated is a pure Java-side construct so there is currently no way to hook in from Lisp, so that part of the concern is unfounded. Still, calling System.exit() seems really wrong. Need to reconsider the reason under which ProcessingTerminated exception was introduced.
Sounds like ext:exit has been converted to do ProcessingTerminated, but it shouldn't actually do that. This strongly suggests that too much has been changed over to ProcessingTerminated; the original reason for converting some uses over is still valid, because in order to work as a library, abcl should avoid exitting.
On Aug 22, 2011, at 11:25 , Ville Voutilainen wrote:
On 22 August 2011 12:21, armedbear <armedbear-devel@common-lisp.net> wrote:
Further analysis reveals that ProcessingTerminated is a pure Java-side construct so there is currently no way to hook in from Lisp, so that part of the concern is unfounded. Still, calling System.exit() seems really wrong. Need to reconsider the reason under which ProcessingTerminated exception was introduced.
Sounds like ext:exit has been converted to do ProcessingTerminated, but it shouldn't actually do that. This strongly suggests that too much has been changed over to ProcessingTerminated; the original reason for converting some uses over is still valid, because in order to work as a library, abcl should avoid exitting.
*sigh* We should probably centralize using the value of a variable as to whether to really exit or not. For the case where SLIME is making thread(s) to handle the Emacs REPL request, EXTENSIONS:EXIT is pretty clearly meant to map to System.exit(). But what should the semantics of EXTENSIONS:EXIT be for "ABCL as library"? Should it try to interrupt all of the currently running LispThreads? When really "used as a library" this may or may not be a good idea, as it might just want to "exit all threads that have been started by the current thread". The question then becomes how can we distinguish between ABCL running as a library vs. running as a process? Maybe somehow mark all possible ways of getting the Interpreter object with a boolean? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 22 August 2011 15:19, Mark Evenson <evenson@panix.com> wrote:
We should probably centralize using the value of a variable as to whether to really exit or not. For the case where SLIME is making thread(s) to handle the Emacs REPL request, EXTENSIONS:EXIT is pretty clearly meant to map to System.exit().
We're singing the same song. I don't want to change what ext:exit does. I'm saying that ext:exit shouldn't cause a ProcessingTerminated exception.
On Aug 22, 2011, at 14:22 , Ville Voutilainen wrote:
On 22 August 2011 15:19, Mark Evenson <evenson@panix.com> wrote:
We should probably centralize using the value of a variable as to whether to really exit or not. For the case where SLIME is making thread(s) to handle the Emacs REPL request, EXTENSIONS:EXIT is pretty clearly meant to map to System.exit().
We're singing the same song. I don't want to change what ext:exit does. I'm saying that ext:exit shouldn't cause a ProcessingTerminated exception.
Sorry, I didn't read your reply carefully enough. Next question: then why is the ProcessingTerminated exception only thrown in the EXT:EXIT and EXT:QUIT implementations? When would we ever expect it to be thrown? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 22 August 2011 15:26, Mark Evenson <evenson@panix.com> wrote:
Next question: then why is the ProcessingTerminated exception only thrown in the EXT:EXIT and EXT:QUIT implementations? When would we ever expect it to be thrown?
I thought it's thrown from the interpreter when cmdline option parsing fails, and possibly in a couple of other places. There should be a clear difference between exit/quit (which are called) and error cases (which throw).
On Mon, Aug 22, 2011 at 2:28 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On 22 August 2011 15:26, Mark Evenson <evenson@panix.com> wrote:
Next question: then why is the ProcessingTerminated exception only thrown in the EXT:EXIT and EXT:QUIT implementations? When would we ever expect it to be thrown?
I thought it's thrown from the interpreter when cmdline option parsing fails, and possibly in a couple of other places. There should be a clear difference between exit/quit (which are called) and error cases (which throw).
IIRC, EXT:EXIT/QUIT used to call System.exit but were reengineered to throw ProcessingTerminated to be more application-server friendly, and in general for cases when ABCL is used as a library as you pointed out. I'm not too satisfied either with the current solution, because the use of ABCL as an application rather than a library becomes more complicated, especially with multiple threads. Perhaps when constructing the interpreter one could pass a callback to use for EXIT/QUIT, defaulting to throw ProcessingTerminated in general, and to System.exit when the interpreter is created from org.armedbear.lisp.Main. Bye, Alessio
participants (3)
-
Alessio Stalla -
Mark Evenson -
Ville Voutilainen