5 ms·

> I mean that they don't require any explicit yields. So in this sense, are Kotlin coroutines also non-cooperative? They don't explicitly yield, but do have a

by haxen 6y ago

> I mean that they don't require any explicit yields. So in this sense, are Kotlin coroutines also non-cooperative? They don't explicitly yield, but do have a mandatory API to use for "blocking" calls.

pron 6y ago
They do explicitly yield, although not with an explicit keyword or call, but with an explicit type. I guess you could say that the "await" is inferred by the compiler, but it's there. That's not the case with virtual threads, which behave more like Go's goroutines or Erlang's processes.
- nahuel0x 6y ago
  Can a Loom scheduler kill a virtual thread in an arbitrary execution point (like Erlang process but unlike goroutines)?
  - 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
- haxen 6y ago
  >They do explicitly yield Arguably, virtual threads also explicitly yield by calling one of the blocking methods in the JDK. This is very similar to putting all the bottom-level suspendable functions into the Kotlin standard library. >virtual threads, which behave more like Go's goroutines or Erlang's processes. I think this can be summarized as "Kotlin uses colored functions and Loom uses non-colored ones". This is a well-established core difference, I thought you had something else in mind with "explicit yield".
  - pron 6y ago
    > Arguably, virtual threads also explicitly yield by calling one of the blocking methods in the JDK. There's nothing explicit here, or nothing more explicit than the ordinary platform threads you use today -- JDK operations might or might not block an OS thread. There is no way you can tell whether a call does that or not, and that behaviour can change (plus, there's forced preemption as an option). > This is a well-established core difference, I thought you had something else in mind with "explicit yield". I would say that an explicit colour for yielding qualifies as an explicit yield, and so falls under cooperative. In any event, virtual threads have neither explicit yield-sites nor special yield-site colours, hence they're non-cooperative, and they support forced preemption.
    - haxen 6y ago
      Without the very last point, forced preemption, they would indeed be cooperative because not calling any blocking method would make them non-cooperative. This is exactly the same as within the "colored" subspace in a language that has this distinction. As long as all the functions you call are suspendable, you equally have no idea which one will actually suspend. So, without forced preemption based on GC safepoints, and as long as there is any blocking operation left in the library, Loom qualifies as a cooperative multithreading system.
      - pron 6y ago
        > Without the very last point, forced preemption, they would indeed be cooperative because not calling any blocking method would make them non-cooperative If user code cannot possibly know whether an operation blocks or not, then it cannot "cooperate." > As long as all the functions you call are suspendable, you equally have no idea which one will actually suspend. First, this is true hypothetically but never in practice. Consider that if code really didn't care about blocking, then why not colour everything in the blocking colour? The answer is that in the coloured mode, compilation and cost of the two colours are very different. Second, and more importantly, the reason that there are two colours is exactly to enable a cooperative style. While a "blocking" routine may or may not block, a non-blocking one never does and that is the crucial difference. With cooperative multi-tasking the default mode is that of a critical section -- there is no scheduling point unless you explicitly know in advance there might be one and where. With preemptive concurrency the default is the opposite: yielding may happen at any time unless you explicitly enter a critical section. This results in very different coding styles. Anyway, we're arguing over definitions, so you may want to consult Wikipedia's definitions [1] [2]. [1]: https://en.wikipedia.org/wiki/Cooperative_multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking [2]: https://en.wikipedia.org/wiki/Preemption_(computing)#PREEMPTIVE https://en.wikipedia.org/wiki/Preemption_(computing)#PREEMPT...

by haxen 6y ago

pron 6y ago

They do explicitly yield, although not with an explicit keyword or call, but with an explicit type. I guess you could say that the "await" is inferred by the compiler, but it's there. That's not the case with virtual threads, which behave more like Go's goroutines or Erlang's processes.

nahuel0x 6y ago
Can a Loom scheduler kill a virtual thread in an arbitrary execution point (like Erlang process but unlike goroutines)?
- 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
haxen 6y ago
>They do explicitly yield Arguably, virtual threads also explicitly yield by calling one of the blocking methods in the JDK. This is very similar to putting all the bottom-level suspendable functions into the Kotlin standard library. >virtual threads, which behave more like Go's goroutines or Erlang's processes. I think this can be summarized as "Kotlin uses colored functions and Loom uses non-colored ones". This is a well-established core difference, I thought you had something else in mind with "explicit yield".
- pron 6y ago
  > Arguably, virtual threads also explicitly yield by calling one of the blocking methods in the JDK. There's nothing explicit here, or nothing more explicit than the ordinary platform threads you use today -- JDK operations might or might not block an OS thread. There is no way you can tell whether a call does that or not, and that behaviour can change (plus, there's forced preemption as an option). > This is a well-established core difference, I thought you had something else in mind with "explicit yield". I would say that an explicit colour for yielding qualifies as an explicit yield, and so falls under cooperative. In any event, virtual threads have neither explicit yield-sites nor special yield-site colours, hence they're non-cooperative, and they support forced preemption.
  - haxen 6y ago
    Without the very last point, forced preemption, they would indeed be cooperative because not calling any blocking method would make them non-cooperative. This is exactly the same as within the "colored" subspace in a language that has this distinction. As long as all the functions you call are suspendable, you equally have no idea which one will actually suspend. So, without forced preemption based on GC safepoints, and as long as there is any blocking operation left in the library, Loom qualifies as a cooperative multithreading system.
    - pron 6y ago
      > Without the very last point, forced preemption, they would indeed be cooperative because not calling any blocking method would make them non-cooperative If user code cannot possibly know whether an operation blocks or not, then it cannot "cooperate." > As long as all the functions you call are suspendable, you equally have no idea which one will actually suspend. First, this is true hypothetically but never in practice. Consider that if code really didn't care about blocking, then why not colour everything in the blocking colour? The answer is that in the coloured mode, compilation and cost of the two colours are very different. Second, and more importantly, the reason that there are two colours is exactly to enable a cooperative style. While a "blocking" routine may or may not block, a non-blocking one never does and that is the crucial difference. With cooperative multi-tasking the default mode is that of a critical section -- there is no scheduling point unless you explicitly know in advance there might be one and where. With preemptive concurrency the default is the opposite: yielding may happen at any time unless you explicitly enter a critical section. This results in very different coding styles. Anyway, we're arguing over definitions, so you may want to consult Wikipedia's definitions [1] [2]. [1]: https://en.wikipedia.org/wiki/Cooperative_multitasking https://en.wikipedia.org/wiki/Cooperative_multitasking [2]: https://en.wikipedia.org/wiki/Preemption_(computing)#PREEMPTIVE https://en.wikipedia.org/wiki/Preemption_(computing)#PREEMPT...