Fork me on GitHub
#core-async
<
2019-04-30
>
Ivan Koz19:04:08

do we consider pipe as a simple version of merge or mix? i mean it looks very similar to both.

Alex Miller (Clojure team)20:04:47

I consider it just to be what it is - a means of connecting two channels

Ivan Koz22:04:34

https://gyazo.com/029c68de8ce3a51a719883d5e87ee780.png Say we don't need the timeout, can it be written better?

(comment
  ;; search async, repllicated, take first
  (let [fake-search (fn [kind query]
                      (Thread/sleep (rand-int 100))
                      (format "%s search result for '%s'" kind query))
        fastest (fn [query ep1 ep2]
                  (go (alt!
                        (go (fake-search ep1 query)) ([v] v)
                        (go (fake-search ep2 query)) ([v] v))))
        search (fn [query]
                 (->> (async/merge [(fastest query "web 1" "web 2")
                                    (fastest query "image 1" "image 2")
                                    (fastest query "video 1" "video 2")])
                      (async/into [])))]
    (time (<!! (search "clojure")))))

hiredman23:04:37

you should never call Thread/sleep inside a go block

hiredman23:04:17

you absolutely should be using timeout channels and not faking it like that

Ivan Koz23:04:40

@hiredman i don't understand why, there is literally no difference between blocking operation and thread sleep inside a function

hiredman23:04:15

you should not have blocking operations inside go blocks

Ivan Koz23:04:27

i know we puy long operations on async/thread

hiredman23:04:31

only parking (channel) operations

Ivan Koz23:04:35

but whats about clojurescript then?

Ivan Koz23:04:54

so no blocking calls at all?

hiredman23:04:35

clojurescript inherits javascripts model, there is a single thread, any blocking/long running operations ever will block anything else

hiredman23:04:23

the threadpool used to run go blocks on the jvm is not single threaded, but that just means you can include blocking things like sleeps and it will work when you test at a small scale, and things will bog down and stop once you are at a large enough scale to saturate the threadpool

hiredman23:04:48

async/thread isn't for "long operations" it is for blocking operations

Ivan Koz23:04:50

yeah thats explains it

hiredman23:04:46

the channel ops like >! and <! appear to block but don't actually block and are sometimes said to "park" instead

Ivan Koz23:04:05

so to sum up; do whatever but don't take thread-pool threads for your long span\blocking calls

Ivan Koz23:04:31

i'm just trying to comprehend what implications we have running csp on a threadpool, rather than green-threads\fibers

Ivan Koz23:04:11

looking at that you wrote, i make conclusion that any IO task in a go block is a no no

hiredman23:04:21

go blocks are basically green threads, and those green threads are run on the real threads in the threadpool

Ivan Koz23:04:04

yeah but you can block green thread

hiredman23:04:16

it depends on the implementation

hiredman23:04:44

most of the time you cannot add green threads as a library, so the entire runtime system is built on around non-blocking io

hiredman23:04:43

so most green thread runtimes turn what appears to be blocking io calls in to non-blocking calls

hiredman23:04:00

go doesn't do that, but does some hand wavy stuff with it detects a go routine is blocked, giving the go routine its own thread

hiredman23:04:59

(hand waving by me because I don't remember and I think it has maybe changed since the last time I read anything about it)

Ivan Koz23:04:06

so inside go block, we should give any long-span\blocking operation it's own thread, except parking stuff

hiredman23:04:52

yes, and generally you want to park on the result of calls to async/thread

Ivan Koz23:04:16

yeah it makes it clear now, thanks

Ivan Koz23:04:10

aside from that above code is fine right?

hiredman23:04:43

alts! might be nicer then alt! there

Ivan Koz23:04:55

same with timeout