Clojurians Log v2

Maybe we should abandon interruptability. JS isolates don't allow for interrupts. Idk if maybe wasm is adding them but I think you have to simulate them in the runtime in wasm iiuc. And with non-interruptable, run-to-completion semantics of isolates, thinking about parallelism is way easier. You can still always terminate the isolate, cancelling it or retrying it like a transaction, but that's your only real interrupt. You can always add in logical interrupts at your application level, with explicit checks in your algorithm, if you need backtracking. But it may well be that interruptability could be a anti-pattern

Hard to build an STM without efficient interruptability though. So an escape hatch would be nice for things like that, rather than having to spawn a whole new thread/isolate

But it's probably an anti pattern in the spirit of programming control flow with exception throwing

It basically makes it impossible for you to have a logically closed process, guaranteed to behave deterministically

Even in the small, unless you can just assume that nobody is calling an interrupt here

But I have almost no experience in actually trying to program with interrupts, so maybe it's just a lack of familiarity

It's cooperative interrupt. The code won't just arbitrarily stop anywhere. The only gotcha is that people often forget that some APIs check for it and might throw. So if you are blocked on some IO, in Java, the IO API from Java will check for interrupt and might throw, and you would need to catch and clean resources associated with the IO. Or if it was a "commit" type of IO, well, why are you cancelling that?

But in general, you should use with-resource if you have cleanup to do post/IO, so you should be good.

That said, I don't know if it's worth the trouble. I have it supported right now. But I'm not sure if it's something people care about or not.

Clojure 1.12.0
user=> (require '[clojure.core.async :as a])
nil
user=> (def t (atom nil))
#'user/t
user=> (a/thread (reset! t (Thread/currentThread)) (.interrupt (Thread/currentThread)))
#object[clojure.core.async.impl.channels.ManyToManyChannel 0x6919a8a "clojure.core.async.impl.channels.ManyToManyChannel@6919a8a"]
user=> (.isInterrupted @t)
false
user=> 

https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java#L1116-L1124

Well, that makes my life so much easier lol. So Java will unset the flag itself when returning (or maybe before reusing) a thread in the pool. If I understood correctly ya?

sure looks like that

Hope so haha. As for the problem itself, I think switching to an atom and doing:

(when-some [t (first (swap-vals! interrupter-thread (constantly nil)))]
                                (.interrupt t))

Hum, it's possible that the thread pool would be smart, but I think in combination with core.async, maybe not, because I think sometimes it will run a completion handler on the same thread and so on. Not sure, but when I remove my own clean up on the interrupted state I start getting some errors elsewhere due to things being interrupted that should not be

Ah... maybe not. I guess I still need to be sure that my go watcher won't interrupt the thread after it is done, because it could in theory do so at a point in time where another task has now picked up the thread again. So ya, I was just stupid a bit, I still need to clear a reference here.

But now this seems to work:

(defn thread-with-java-style-cancel
     [body-fn]
     (let [ret (promise-chan)
           interrupter-thread (volatile! nil)
           interrupter (go
                         (when (some? (<! ret))
                           (when-some [t @interrupter-thread]
                             (.interrupt t))))]
       (thread
         (vreset! interrupter-thread (Thread/currentThread))
         (try
           (when-not (poll! ret)
             (let [result (try (body-fn)
                               (catch Throwable t
                                 t))]
               (vreset! interrupter-thread nil)
               (offer! ret result)
               (close! ret)))
           (finally
             (vreset! interrupter-thread nil))))
       ret))

Hum... or I wonder if this can have the same race condition, just even less likely to happen. Even though the thread interrupt will be reset properly by the pool, the go block could outlive this execution, and if it read the thread before it was set to nil, it could interrupt a thread that is now used by something else.