cider’s interrupt is a deprecated and not great way to stop a thread. But I think you are forgetting what you have done: cancelling a thread is one thing. But you have launched a bunch of other tasks on other threads and hope that your cancellation is transitively passed along to the other threads you’ve started. I don’t think that’s in the realm of what is offered by the thread cancellation

Cider-interrupt is deprecated? the docs don't indicate as much. huh. I guess communicating state between parallel processes sounds like a job for core async or something like that then right?

the method by which it tries to stop a thread is deprecated

(defn- interrupt-stop
  "This works as follows

  1. Calls interrupt
  2. Wait 100ms. This is mainly to allow thread that respond quickly to
     interrupts to send a message back in response to the interrupt. Significantly,
     this includes an exception thrown by `Thread/sleep`.
  3. Asynchronously: wait another 5000ms for the thread to cleanly terminate.
     Only calls `.stop` if it fails to do so (and risk state corruption)

  This set of behaviours strikes a balance between allowing a thread to respond
  to an interrupt, but also ensuring we actually kill runaway processes.

  If required, a future feature could make both timeouts configurable, either
  as a server config or parameters provided by the `interrupt` message."
  [^Thread t]
  (.interrupt t)
  (Thread/sleep 100)
  (noisy-future
   (Thread/sleep 5000)
   (when-not (= (Thread$State/TERMINATED)
                (.getState t))
     (.stop t))))

And that just effects the evaluation thread

Other threads like the ones in the threadpool pmap uses remain unaffected

You can also search the slack for discussions about pmap

Pmap mixes laziness and concurrency so hard to say, but generally when you interrupt it you are just interrupting the waiting for it to complete, the threads doing the work keep going

@U0NCTKEV8, that makes sense. Thanks.

thanks for sharing that code dpsutton 👍