3 ms·

Why do you call alts! input choices as non deterministic ?

sgrove 13y ago
You won't know which channel is going to give you a value ahead of time, it depends on runtime conditions. But really, you don't care if the user pushes the keyboard or moves the mouse first, you just want to handle each event as it happens in essentially a sequential manner.
- realrocker 13y ago
  If I am forcing it to be sequential, aren't the choices now determinitic?
  - brandonbloom 13y ago
    The default for multiplexing is non-deterministic choice. You can specify the :priority flag [1] if you want deterministic choice when multiplexing. Reads and writes will block for a non-deterministic amount of time, but their sequencing will be deterministic. That's the beauty of the CSP model: You can achieve some level of local determinism within a particular thread of control. Makes it much easier to reason about the non-deterministic outside world. [1]: https://github.com/clojure/core.async/blob/bb77337b3e9ce2118916fe84ae37c064a2eb9c55/src/main/clojure/clojure/core/async.clj#L229 https://github.com/clojure/core.async/blob/bb77337b3e9ce2118...
    - realrocker 13y ago
      makes sense , thank you!
brandonbloom 13y ago
Any time you're dealing with multiple control paths (regardless of if they are real threads, logical threads, callbacks, asynchronous messaging, etc), small changes in timing or synchronization will introduce non-determinism. For example, you don't know how quickly a remote service is going to respond. If you had some code that communicated with channels and used only a single real thread without using any non-deterministic operations, then you'd actually have deterministic choice. So if you write a unit test with some mock services, you would always read from a particular service because the execution is truly deterministic. That might also mean that if two services respond at similar times (even non-deterministically) and you prefer one over another in at a choice, you could wind up unfairly ignoring one of the channels. To combat this issue, Golang & core.async introduce randomness when multiplexing. If two channels are both ready, one is selected at random.

You won't know which channel is going to give you a value ahead of time, it depends on runtime conditions. But really, you don't care if the user pushes the keyboard or moves the mouse first, you just want to handle each event as it happens in essentially a sequential manner.

realrocker 13y ago
If I am forcing it to be sequential, aren't the choices now determinitic?
- brandonbloom 13y ago
  The default for multiplexing is non-deterministic choice. You can specify the :priority flag [1] if you want deterministic choice when multiplexing. Reads and writes will block for a non-deterministic amount of time, but their sequencing will be deterministic. That's the beauty of the CSP model: You can achieve some level of local determinism within a particular thread of control. Makes it much easier to reason about the non-deterministic outside world. [1]: https://github.com/clojure/core.async/blob/bb77337b3e9ce2118916fe84ae37c064a2eb9c55/src/main/clojure/clojure/core/async.clj#L229 https://github.com/clojure/core.async/blob/bb77337b3e9ce2118...
  - realrocker 13y ago
    makes sense , thank you!

brandonbloom 13y ago

Any time you're dealing with multiple control paths (regardless of if they are real threads, logical threads, callbacks, asynchronous messaging, etc), small changes in timing or synchronization will introduce non-determinism. For example, you don't know how quickly a remote service is going to respond. If you had some code that communicated with channels and used only a single real thread without using any non-deterministic operations, then you'd actually have deterministic choice. So if you write a unit test with some mock services, you would always read from a particular service because the execution is truly deterministic. That might also mean that if two services respond at similar times (even non-deterministically) and you prefer one over another in at a choice, you could wind up unfairly ignoring one of the channels. To combat this issue, Golang & core.async introduce randomness when multiplexing. If two channels are both ready, one is selected at random.