Fork me on GitHub
#core-async
<
2023-06-02
>
henrik13:06:25

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.

henrik13:06:31

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.

ghadi13:06:35

don't close timeouts

ghadi13:06:02

They are designed to be closed by The System™

henrik14:06:51

I’m not closing them, The System is.

henrik14:06:12

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

ghadi14:06:53

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

hiredman15:06:30

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

hiredman15:06:40

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

hiredman15:06:32

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