This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # alda (10)
- # beginners (15)
- # boot (16)
- # business (2)
- # clojure (68)
- # clojure-czech (1)
- # clojure-italy (3)
- # clojure-japan (71)
- # clojure-russia (32)
- # clojure-uk (2)
- # clojurescript (134)
- # core-async (84)
- # datomic (27)
- # devcards (13)
- # hoplon (3)
- # ldnclj (8)
- # ldnproclodo (1)
- # lein-figwheel (2)
- # melbourne (1)
- # off-topic (29)
- # om (53)
- # re-frame (7)
- # reagent (15)
- # yada (50)
anyone: what is the appropriate way to wait for all or a group of go processes to finish?
ajmagnifico: that sounds similar to the problem jeremyraines just asked about, above. See his gist for an example of composing
http://dev.clojure.org/jira/browse/ASYNC-65 Rich has vetted that. It would enable you to do what you need
not sure i follow you.
pipe is an operation from channel to channel. it doesn't do any work besides scuttle data from in to out
i was using pipelines and transducers and was looking to convert that to channels w/ transducers and
after realizing i don’t need the parallelism, i decided to try putting the transducers in the channels and using
@gabe: maybe a slight aside, but my new favourite way of doing multiple async calls and gathering results is applicative-do syntax (alet) - http://funcool.github.io/cats/latest/#channel - if you use an async network client you don't need to create any threads at all (beyond the client's service pool)
@gabe: the relevant concept being the deferred - https://github.com/ztellman/manifold/blob/master/docs/deferred.md
@gabe: i'm using it in a system with mixed core.async and manifold async components and it's been working great
if you do use it, you can go all high-level with applicative-do syntax too - http://funcool.github.io/cats/latest/#manifold-deferred
@erik_price or anybody: Yesterday I asked about waiting for go processes to finish. Here's something I came up with.
OK, here's a more straightforward question: is there API for determining if a channel is closed? If it still has values available for taking?
Or, given a channel that resulted from a
(go) call, is there a way to distinguish between
nil (channel closed, no values to take) and
nil (`(go (println "hey"))` returned
generally inspecting a channel is race-condition prone. If you ask it if it's closed, and it says no, it may be closed by the time you act upon that information
there isn't any difference is there ? the result of (go (println "hey")) is a closed channel with no values to take
there might just be times when I want all go processes to complete before proceeding with the remainder of the program.
It turns out it's mostly equivalent to (but probably less robust than)
(merge [channels ...])
otherwise, at a high level, you just gotta remember what you launched off and wait for the channels that represent those tasks
Golang's waitgroup stuff warns:
Typically this means the calls to Add should execute before the statement creating the goroutine or other event to be waited for.
part of my problem is that when I'm incrementally writing experimental code in emacs/cider and trying to test this stuff out, the full expression typically ends before the go processes have completed.
The await-go-processes function that I wrote keeps track of all the channels returned from (go) calls, and alts!! them until all have returned.