Fork me on GitHub

Are there any plans to get “Interrupt Current Evaluation” working for socket repls?


I'm not sure that's possible, I think it's a feature of nrepl


It’s possible. It’s a matter of what payload you use to set things up.


nrepl just wraps every execution on a thread, and it calls Thread/kill on cancelation


At worst cursive would rely on the user to set up a specific :accept fn.


I see. I'm probably not well-informed in the topic, I only based my initial comment on what I read in the article I linked


Cursive could do this, yes, since it implements a simple protocol over a socket REPL. However there are complications with that, as you might expect - each eval is then in a different thread and needs dynamic bindings propagated etc. Currently with socket REPLs the evaluations are strictly sequential, but once evals are in separate threads that’s no longer the case, and there is potential weirdness around that too. In general the idea with the socket REPL was to try to keep things simple, and I’m not sure whether that counts 🙂


Yeah, I prefer the mental model for sure. Unfortunately, a great deal of my work involves starting an infinite loop of some sort, and being unable to run them without restarting a repl really stinks.


Cursive’s protocol is similar to pREPL, but it’s structured in both directions, not just on returns.


Yeah, I can see that. I guess one potential middle ground would be to use a single background thread for evals which could be cancelled. That would maintain the sequential nature, but would still require bindings to be maintained etc.


Aren’t bindings mostly out-of-the-box via bound-fn*?


Or am I missing smth?


otoh, now that you say that, I could just take care to always kick those off in a future.


somehow never occurred to me :derp:


Right, you could always do it manually yourself, which is a bit fiddly but possible.


But I also really like that middle ground that you mention, if you ever get around to it. No complicated session mgmt business. Just a dedicated solo thread pool.


In the meantime I’ll try out being vigilant with my infinite loops. If I fail catastrophically, I’ll be sure to let you know 😉


But as you can see, there’s really no thread management required at all, which keeps it really nice and simple.

👍 3

And no fiddly bindings management.


oh I know nrepl


I would never ask you to go there 😄


I was unlucky enough to have a serious run in with piggieback. The beast is real.


Haha, I have to go there pretty regularly. Anyway, the answer is: it’s possible, but I’m not sure it’s desirable. I’d have to try a PoC and see how it ends up.


Well, piggieback is a whole extra level of madness.

💯 3

Yeah, well. Consider it un-asked until I get back to you. I don’t think it’s crazy to pre-wrap in a future and self-manage.


I was kind of stuck in the mindset of, “Feature exists here. I want it there.”


Hehe, totally fair enough. Let me know if manually wrapping either doesn’t work or is unreasonably painful. You could potentially use REPL commands to make it easier.

👍 3

@U07S8JGF7 afaik, nREPL uses Thread#stop which has long been deprecated


I have a similar problem with the nREPL server of babashka. I can't use Thread#stop there because it's not supported anymore in the GraalVM JDK


Someone on the graalvm slack suggested to me to use safepoints


haven't looked into it though


It does use stop, but I’ve never had a problem with it.


AFAIK the biggest problem with stop is that it doesn’t release monitors — which aren’t really an issue in clojure.


at any rate, an interrupt would probably do


an interrupt won't kill a thread running (doall (range))


There’s no way to kill that (or in general, any uncooperative REPL process) except Thread/kill


you mean Thread#stop right


Yes, that one.


BTW the problem is not actually that monitors are not released, it’s quite the opposite: > Stopping a thread causes it to unlock all the monitors that it has locked. (The monitors are unlocked as the ThreadDeath exception propagates up the stack.) If any of the objects previously protected by these monitors were in an inconsistent state, other threads may now view these objects in an inconsistent state. Such objects are said to be damaged. When threads operate on damaged objects, arbitrary behavior can result. This behavior may be subtle and difficult to detect, or it may be pronounced. Unlike other unchecked exceptions, ThreadDeath kills threads silently; thus, the user has no warning that his program may be corrupted. The corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future.


The risk is pretty low for a REPL IMO

✔️ 5

Ah yeah, that’s right.