Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-01-17

Channels

#core-async
<
2021-01-17
>
Faiz Halde18:01:29

any idea why a thread/go-block that’s blocked/parked on a channel does not resume when we close that channel (channel closing happens after it’s already blocked/parked) e.g. 

(def c (chan))

(future
  (alt!!
    [[c "value"]] :done))

(close! c) ;; expected alt!! to return since all its clauses are never going to succeed now

Faiz Halde19:01:38

ok nevermind. understood. the expectations with writes is that someone may want to read it

Faiz Halde19:01:19

and once all reads have happened the thread/goroutine will unblock

hiredman22:01:47

There are some bugs open for this

Faiz Halde14:01:54

posting on a wider channel for visibility thanks @hiredman btw, do you think there are any best practices on how to gracefully shutdown a core async system? i’m hitting cases where some systems close the channels and there’s often a race condition that causes the upstream go blocks to block forever if `>!` precedes the `close!` & nobody is there to read what’s put. essentially causing a deadlock for now what i’m thinking is to use `alts!` as much as possible rather than doing any puts/gets serially via `<!` or `>!` .. this way i can have a controller channel that alts will be waiting on (along with other channels). this way I can do an early termination Other way would be to think of my systems message passing as a FSM and only allow a shutdown at a safepoint

jjttjj14:01:57

I use this for these cases to ensure the channels are not blocking anything when they're closed 

(defn drain! [ch]
  (a/close! ch)
  (->> (repeatedly #(a/poll! ch))
       (take-while identity)
       doall))

Faiz Halde14:01:46

did think of this. i might as well proceed with this for now and think of a clean strategy later

Faiz Halde14:01:54

posting on a wider channel for visibility thanks @hiredman btw, do you think there are any best practices on how to gracefully shutdown a core async system? i’m hitting cases where some systems close the channels and there’s often a race condition that causes the upstream go blocks to block forever if `>!` precedes the `close!` & nobody is there to read what’s put. essentially causing a deadlock for now what i’m thinking is to use `alts!` as much as possible rather than doing any puts/gets serially via `<!` or `>!` .. this way i can have a controller channel that alts will be waiting on (along with other channels). this way I can do an early termination Other way would be to think of my systems message passing as a FSM and only allow a shutdown at a safepoint