core-async

henrik 2023-06-02T13:28:25.441759Z

Why is timeout in CLJS not just,

(defn timeout
  [ms]
  (let [ch (chan)]
    (js/setTimeout #(close! ch) ms)
    ch))
I see that there’s a lot of stuff happening in the implementation, so I assume the above is naive, but I don’t understand why.

henrik 2023-06-02T13:31:31.513219Z

The reason I’m asking is because I’m running into weird behaviour with timeout, where closing one timeout seems to close another, unrelated one (no pipes etc. involved, or other things that might propagate), and the naive version seems to work as expected.

ghadi 2023-06-02T13:58:35.086149Z

don't close timeouts

ghadi 2023-06-02T13:59:02.213869Z

They are designed to be closed by The System™

henrik 2023-06-02T14:16:51.010059Z

I’m not closing them, The System is.

henrik 2023-06-02T14:18:12.683449Z

But I’m also curious why they require so much infrastructure.

ghadi 2023-06-02T14:43:53.464229Z

at least on the JVM side, timeouts are quantized at a resolution of 10ms

2023-06-02T15:12:30.921919Z

If you were going to change how timeouts are implemented in cljs I wouldn't go with exactly that, it perpetuates a big issue with the current design of timeouts, a strong reference to the timeout channel is kept by the global system that closes the timeout channels

2023-06-02T15:21:40.082219Z

https://clojure.atlassian.net/browse/ASYNC-109 I forgot about this, which has a cljs patch as well

2023-06-02T15:22:32.842169Z

It changes timeouts to return a custom ReadPort instead of a channel, so you get an error if close! Is called on them