This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-21
Channels
- # announcements (1)
- # bangalore-clj (1)
- # beginners (5)
- # calva (20)
- # cider (5)
- # clj-kondo (6)
- # clojure-czech (1)
- # clojure-dev (22)
- # clojure-hk (5)
- # clojure-norway (9)
- # clojure-switzerland (1)
- # clojure-uk (22)
- # clojurescript (7)
- # code-reviews (26)
- # cursive (1)
- # data-science (1)
- # datomic (1)
- # emacs (1)
- # fulcro (24)
- # off-topic (43)
- # om (1)
- # pathom (5)
- # pedestal (1)
- # re-frame (9)
- # reagent (1)
- # shadow-cljs (1)
- # spacemacs (7)
- # sql (4)
- # xtdb (8)
Hi, everyone Are an Atom's swaps in danger of starvation ? (since I looked at the code and didn't find a mechanism to prioritize older swaps or am I wrong?)
We wanted to use atom in a stream-processing (kind-of) application.
But we need to make sure that swaps don't get delayed indefinitely.
Under the covers it's just invoking AtomicReference.compareAndSet in a loop, so there is the chance of livelocking a thread if the value of the atom keeps changing between reading the old value and calling CAS.