Ctrl-C in REPL

[Parth Malwankar]

Hello,

Sometimes in the REPL we end up making some mistake
like (repeat 1) which just doesn't end.
At this point I end up doing a Ctrl-C.

Clojure
user=> (repeat 1)
(1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1
1[parth:~]%

The only issue is that this terminates the REPL and I exit
to the unix shell.

Is there anything that can be done to break something like
(repeat 1) but still not exit the Clojure REPL?

Thanks.
Parth

[Chouser]

On Tue, Aug 12, 2008 at 1:20 PM, Parth Malwankar
<parth.m...@gmail.com> wrote:
>
> Is there anything that can be done to break something like
> (repeat 1) but still not exit the Clojure REPL?

(sun.misc.Signal/handle
(sun.misc.Signal. "INT")
(proxy [sun.misc.SignalHandler] []
(handle [sig] (throw (Exception. (str sig))))))

...except that's actually worse (at least for this platform and
version of Java) as it is catches the Ctrl-C (preventing the Repl from
dying) but then process it in its own thread, allowing all other
threads (notably the one we're trying to stop) to continue.

Which helps focus the question -- which exact threads should be
stopped by Ctrl-C? Just the Repl's thread I suppose?

--Chouser

[Michael Reid]

Hi,

> Which helps focus the question -- which exact threads should be
> stopped by Ctrl-C? Just the Repl's thread I suppose?
>

I think you'd somehow want to interrupt the call to:

75: Object ret = Compiler.eval(r);

in Repl.java. Not sure if this can be done though, as I don't see any
way to interrupt the execution of this thread. You could potentially
try destroy()ing (although the 1.4 docs say this is unimplemented) the
Repl and then launching a new thread to start it again.

If Thread.destroy() works, you might be able to get ok results by
re-architecting Repl.java to launch the call to Compiler.eval() in a
new thread, and then the signal handler would just call
Thread.destroy() to kill the runaway evaluation.

Who knows how this actually behaves though.

There might be some APIs that would help with this, but my suspicion
is that doing this reliably would not be trivial.

/mike.