6 ms·

http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.html#forced-preemption http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.h... Yes it can an

by haxen 6y ago

http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.html#forced-preemption http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.h... Yes it can and actually it's quite low-hanging fruit on the JVM. GC safepoints are already there, you just have hook into the mechanism.

pron 6y ago
True, but it heavily depends on what you mean by "can." Doing it safely in Java is a problem, as Java code does not protect from shared state. So I would say it's "sort-of, but not really, as it would be very dangerous unless you know exactly what the thread is doing." On the other hand, if the question is, if Erlang were implemented on the Java platform using virtual threads as processes, would code be able to kill a process arbitrarily, then the answer would be yes.
- nahuel0x 6y ago
  It can be useful for killing a clojure virtual thread who only uses shared memory by reading thread-safe persistent data structures and writes only to clojure atoms/STM (besides his unshared local state). If this is possible, then Loom + clojure can be a better model than erlang for some usages. Myriads of linked actors but with the added feature of shared memory for global views (see Rich Hickey criticism of the actor model) and optimized message passing (you don't need to copy messages if you have a global GC and they are clj persistent data structures). But external killing of a linked actor/vthread -one of erlang usually ignored secret sauces- is fundamental, if not, you need adhoc mechanisms like Go cancellation contexts who IMHO adds a lot of error prone accidental complexity. Think usages beyond supervisors/fault-tolerance like killing obsolete requests/computation or speculative execution.
  - pron 6y ago
    The problem here is that Clojure only appears to other Clojure code to do what you're describing, but heavily relies on mutation and locking under the covers. Any lazy seq in Clojure is actually a mutable data structure that guards mutation with locks. Clojure, however, could emit instructions that check for interruption at sites that are safe for Clojure to interrupt a thread.
    - nahuel0x 6y ago
      Just to understand you better, Clojure lazy-seqs are thread-safe but the Loom killing mechanism is not compatible with sections guarded with locks? So, if you had: try { lock.lock() // long computation here, no interrupts check } finally { lock.unlock() } What happens when the virtual thread is externally killed in the middle of the long computation? Nothing at all because is not manually checking for the interrupt token? (like Go, unlike Erlang). Or is interrupted but the finally block is not executed and we get a dangling lock? I know Loom is not finished yet, but I would like to know about his prospective.
      - pron 6y ago
        The forced preemption mechanism that uses VM handshakes doesn't care about locks, so it could hypothetically preempt and kill the thread inside the long computation. If you want to insert explicit interruption checks, that's another matter, and it doesn't require the forced preemption mechanism at all.

by haxen 6y ago

pron 6y ago

True, but it heavily depends on what you mean by "can." Doing it safely in Java is a problem, as Java code does not protect from shared state. So I would say it's "sort-of, but not really, as it would be very dangerous unless you know exactly what the thread is doing." On the other hand, if the question is, if Erlang were implemented on the Java platform using virtual threads as processes, would code be able to kill a process arbitrarily, then the answer would be yes.

nahuel0x 6y ago
It can be useful for killing a clojure virtual thread who only uses shared memory by reading thread-safe persistent data structures and writes only to clojure atoms/STM (besides his unshared local state). If this is possible, then Loom + clojure can be a better model than erlang for some usages. Myriads of linked actors but with the added feature of shared memory for global views (see Rich Hickey criticism of the actor model) and optimized message passing (you don't need to copy messages if you have a global GC and they are clj persistent data structures). But external killing of a linked actor/vthread -one of erlang usually ignored secret sauces- is fundamental, if not, you need adhoc mechanisms like Go cancellation contexts who IMHO adds a lot of error prone accidental complexity. Think usages beyond supervisors/fault-tolerance like killing obsolete requests/computation or speculative execution.
- pron 6y ago
  The problem here is that Clojure only appears to other Clojure code to do what you're describing, but heavily relies on mutation and locking under the covers. Any lazy seq in Clojure is actually a mutable data structure that guards mutation with locks. Clojure, however, could emit instructions that check for interruption at sites that are safe for Clojure to interrupt a thread.
  - nahuel0x 6y ago
    Just to understand you better, Clojure lazy-seqs are thread-safe but the Loom killing mechanism is not compatible with sections guarded with locks? So, if you had: try { lock.lock() // long computation here, no interrupts check } finally { lock.unlock() } What happens when the virtual thread is externally killed in the middle of the long computation? Nothing at all because is not manually checking for the interrupt token? (like Go, unlike Erlang). Or is interrupted but the finally block is not executed and we get a dangling lock? I know Loom is not finished yet, but I would like to know about his prospective.
    - pron 6y ago
      The forced preemption mechanism that uses VM handshakes doesn't care about locks, so it could hypothetically preempt and kill the thread inside the long computation. If you want to insert explicit interruption checks, that's another matter, and it doesn't require the forced preemption mechanism at all.