Fork me on GitHub
#shadow-cljs
<
2023-05-15
>
stopa18:05:09

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?

thheller19:05:00

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
thheller19:05:44

2) ws-in is expected to be a buffered channel, but yes it would drop messages if that buffer is full

👍 2
thheller19:05:27

if I was to write this again today I maybe wouldn't use core.async again

thheller19:05:32

I do like the channels abstraction, but go is fairly annoying with all the considerations you have to make

thheller19:05:41

but I guess thats the nature of async, every solutions has its pros/cons

👍 2
stopa19:05:43

Thank you @U05224H0W! This context helps a lot