Fork me on GitHub
#core-async
<
2016-03-31
>
royalaid01:03:09

Hi all, I have a quick question. Why does this block?

royalaid01:03:14

Or rather, why does work for one value and then block

royalaid01:03:49

My impression is that the go-loop in the background will take values as they are added to the channel and the map function will fill the channel as space becomes available

tomjack03:03:41

@royalaid you forgot to recur

tomjack03:03:16

go-loop is just go loop

royalaid07:03:07

Okay cool thanks! I also discovered that adding to a channel with map results in lazy list and won't put the results in a channel so you have to force it with a doall/doseq/dorun

joachim12:03:02

Hi all, I’m trying to figure out if we’re affected by ASYNC-138. So am I right that any go-block internal reference to objects defined outside the go-block is a potential source of mem-leaks?

bronsa12:03:12

values closed over by go-blocks will not be GC'ed until the go block itself gets GC'ed, and if the go-block is for example, a go-loop that recurs infinitely, then those objects will never be freed.

joachim12:03:34

k, thanks!

alexmiller13:03:43

I think it's good advice to do as little as possible actually inside the syntactic go block anyways

alexmiller13:03:18

primarily coordinating with channel ops and calling (ideally) pure functions that transform data

bronsa14:03:08

that's good advice, but trying doing as little as possible in a go block won't save you from exhausting memory when using functions you might not realize are internally using go, e.g. onto-chan

joachim14:03:28

Any chance these issues will eventually be fixed?