This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-05-15
Channels
- # babashka (12)
- # beginners (88)
- # calva (6)
- # cider (4)
- # clerk (110)
- # clojure (18)
- # clojure-czech (1)
- # clojure-europe (26)
- # clojure-nl (1)
- # clojure-norway (7)
- # clojure-poland (8)
- # clojure-spain (2)
- # clojure-uk (2)
- # clojurescript (22)
- # cursive (11)
- # data-science (1)
- # datalevin (5)
- # datomic (35)
- # events (1)
- # fulcro (2)
- # gratitude (5)
- # helix (4)
- # hoplon (20)
- # hyperfiddle (52)
- # jobs (3)
- # lsp (1)
- # malli (48)
- # missionary (11)
- # off-topic (31)
- # practicalli (1)
- # reitit (7)
- # releases (1)
- # remote-jobs (7)
- # scittle (9)
- # shadow-cljs (7)
- # sql (11)
- # xtdb (5)
Hey team, two curious questions about the implementation in shadow-undertow
if you get time. This more to help my understanding of io + core async, and isn't really a bug report. I am doing something similar for my project, and the context would be helpful.
1. Websockets/sendTextBlocking
https://github.com/thheller/shadow-undertow/blob/master/src/main/shadow/undertow.clj#LL479C7-L479C7
;; try to send message, close everything if that fails
(do (try
(WebSockets/sendTextBlocking msg channel)
;; just ignore sending to a closed channel
(catch ClosedChannelException e
(async/close! ws-in)
(async/close! ws-out)))
(recur))))
Here, it looks like we do blocking io inside a go loop. I know Websockets
has a sendText
, so this ~could be translated into an async call. Why was sendTextBlocking
used? Is it because it doesn't really matter in practice, or was there a different reason?
2. async/put!
https://github.com/thheller/shadow-undertow/blob/master/src/main/shadow/undertow.clj#L452-L457
(if-not (some? msg)
(async/close! ws-in)
(async/put! ws-in msg)))
I noticed the async/put!
to send messages to ws-in
. Wouldn't this quietly drop messages if in
couldn't accept messages anymore? How do you think about it?1) considering the context of the tool the blocking send isn't an issue. I certainly would adjust it for something that needs more scale. it was just used because its the simplest to use. marrying one async mechanism with another sucks.
2) ws-in is expected to be a buffered channel, but yes it would drop messages if that buffer is full
I do like the channels abstraction, but go
is fairly annoying with all the considerations you have to make
Thank you @U05224H0W! This context helps a lot