This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-08-29
Channels
- # babashka (54)
- # beginners (24)
- # biff (23)
- # calva (14)
- # catalyst (4)
- # cider (20)
- # clj-kondo (17)
- # clojure (65)
- # clojure-europe (14)
- # clojure-norway (177)
- # clojure-uk (1)
- # clojurescript (11)
- # core-typed (4)
- # cursive (10)
- # datomic (39)
- # emacs (21)
- # gratitude (33)
- # honeysql (8)
- # hyperfiddle (57)
- # introduce-yourself (7)
- # jobs (5)
- # leiningen (17)
- # lsp (6)
- # meander (3)
- # missionary (5)
- # pathom (2)
- # polylith (4)
- # re-frame (7)
- # releases (2)
When waiting for multiple tasks there is m/join
and m/race
which in terminology of JS Promises are like Promise.all
and Promise.race
respectively. Is there an equivalent to Promise.allSettled
which would wait for all tasks to complete (either success or failure) and does not cancel other tasks when some task fails?
you can build it with attempt
:
(defn all-settled [& tasks]
(apply m/join vector (map m/attempt tasks)))
the task result will be a vector of zero-argument functions that you can call with try/catch to check statusAdding to my missionary-contrib namespace (currently embedded in Electric, will extract it at some point)
Thinking about how Missionary can help with > https://www.juxt.pro/blog/clojure-in-griffin/#testing-for-correctness > Allen: So a thing Iāve been banging around for a while, but havenāt really made any progress on yet is around testing of systems. ... two big problems that we have to deal with. One of them is race conditions, and the other is system errors. As a bank we have to be what is called āoperationally resilientā, which really just means no downtime. > What the Foundation team did was build a simulator of the database. They have something like 20 different process types, so 20 different ārolesā within the Foundation cluster, and they wrote them as single-threaded C++ apps. Then they built an actor-model concurrency compiler on top of C++. Every single system call or network call that they make goes through a protocol, so they can inject errors. All of their multi-threading also happens through this actor model with the sending of messages. > With all this in place, they can then say, āOh, what happens if I send message A and then send message B, but then on the other end it arrives B and then A?ā. Or āWhat happens if, in the middle of processing this message, I try to write to disk and I get an error?ā. They can inject errors anywhere in the system, deterministically. > You can think of it as kind of like test.check generative testing, where you have all non-determinism in the system seeded from a single random number that you control. You can control disk errors, network errors, and reordering of messages. Iām really interested in having something like that. The problem right now is that thereās no way to control the behavior of the underlying Java threading libraries, nio, and writing to disk.