External interruption support

[whilo]

Is your feature request related to a problem? Please describe.
When embedding SCI as a sandboxed evaluator, there's currently no built-in way to bound execution time, iteration count, or memory usage per context. Runaway user scripts — infinite loops, deep recursion, unbounded reduce — can consume the host JVM's thread indefinitely, requiring coarse external mechanisms like thread interruption or a global timeout that apply across all contexts equally.

Describe the solution you'd like
An optional :interrupt-fn callback in the SCI context options. When provided, it is called on every function entry (covering loops, dotimes, while, direct recursion, and mutual recursion). The function can throw to abort execution. Because it's captured at function-creation time as a closed-over local, the check is a free nil test when not configured — zero overhead for existing users.

This enables per-context limits: iteration counts, JVM-allocated-bytes checks (ThreadMXBean.getThreadAllocatedBytes), or Thread/interrupted polls, each with independent thresholds per sandbox.

Describe alternatives you've considered

• External thread interruption: works but is global and requires managing threads explicitly.
• A global step counter: no per-context isolation.
• Fuel/quota passed through the interpreter: would require invasive changes to every eval site.

[borkdude]

What about things like (doall (range))? there's (currently) no way to interrupt this, so the interrupt-fn is only partially useful?

[whilo]

I think the right way to do it is along these lines by optionally providing interpreted functions whilo@1b95e6f. This has to be exhaustive, I can work towards this if you give me guidance. But I am also happy to take another route if you see one.

[borkdude]

@whilo I've had this request before but those requests were more specific. Add (.isInterrupted (Thread/currentThread)) checks everywhere, but I found that not appealing since this gave the illusion that all SCI programs could be interrupted, while large parts of core aren't. One solution could be to write your own core functions and override those in SCI. This is already possible so I think we should hold off on including them in the PR right now: with :interrupt-fn you could just insert your own core functions that are aware of :interrupt-fn into {:namespaces {'clojure.core {...}}. There's lots of other core functions with which you can create long running programs by creating large data structures and just running map etc over those.

Examples:

frequencies, group-by, sort, sort-by, distinct, reverse,
vec, set, mapv, filterv, reduce-kv, partition,
partition-by, zipmap, merge, merge-with, concat, flatten,
reductions.

• More examples of long running programs that bypass interrupt-fn:

  (.pow (biginteger 10) 10000000)       ; heavy CPU in one call
  (re-matches #"(a+)+$" "aaaa…aaab")    ; catastrophic backtracking
  (Thread/sleep Long/MAX_VALUE)          ; blocks forever (although this can be interrupted by interrupting the thread)
  (clojure.string/replace huge-string #"x" "y")

• Another gap is host functions that users provide. Those should be made interrupt-fn aware. This effort is on the user I guess.

• Host iteration primitives with no SCI callback:

  (.count (.stream big-list))
  (java.util.Collections/sort big-list)

• Reader-fed construction: (read-string "[…large literal…]") builds
  a large collection in a single host call, without touching interrupt-fn.

My impression is that you basically have to rewrite almost all of clojure.core to make programs fully interruptible which make :interrupt-fn only useful in very specific scenario's.

The only way to get a fully interruptible program right now is to run it in a different process and kill the process.