core-async

hindol 2019-12-14T05:48:01.065600Z

Hi, is future a lightweight thread similar to go blocks?

2019-12-14T06:07:41.065800Z

No

2019-12-14T06:11:59.070500Z

"lightweight thread" is a kind of terrible term

2019-12-14T06:12:42.071500Z

I am not sure I would call go blocks lightweight threads either

2019-12-14T06:13:27.072500Z

When a go block is running it is a normal jvm (native) thread

hindol 2019-12-14T06:15:20.075300Z

Hmm

2019-12-14T06:15:30.076Z

But when "blocked" on a channel it yields the thread. But the amount of data the go block hangs on to can easily dwarf the amount of data needed for thread bookkeeping. So what even is lightweight?

hindol 2019-12-14T06:15:34.076200Z

I kind of what you are trying to say.

hindol 2019-12-14T06:15:42.076400Z

*get

hindol 2019-12-14T06:17:13.078700Z

So, a go block is just description of work, and a thread might pick it up and do a bit of it till time slice runs out or it hits a blocking call. Is that correct?

2019-12-14T06:17:52.079700Z

There is no time slice for go blocks, they are effectively cooperatively scheduled

2019-12-14T06:19:21.081900Z

(the native thread it is running on of course can be preempted, but the go block has no idea of that happens and it doesn't cause it to yield the thread to other go blocks)

hindol 2019-12-14T06:20:30.083900Z

So, when does the go block yield? Is it ONLY when it hits a parking call?

2019-12-14T06:20:52.084700Z

Yes, only on the special channel operations

hindol 2019-12-14T06:21:25.086300Z

That clears it. So, go blocks in a way mandate the use of channels.

2019-12-14T06:21:47.087200Z

Blocking io, taking locks, burning cpu without doing channel ops will all blockup the thread pool where go blocks run

2019-12-14T06:21:51.087500Z

Yes

hindol 2019-12-14T06:22:32.088500Z

I thought is was more general purpose. Thanks for the clarification.

2019-12-14T06:23:31.090100Z

The go macro is also a statically scoped transformation. So it only rewrites it's immediate body.

hindol 2019-12-14T06:24:54.091900Z

You are referring to the concept where a go block stops at the function boundary? I read the official guide but did not understand it fully.

roklenarcic 2019-12-14T14:05:09.094400Z

it will not work if you move <! into a function, it has to be in the go block

dharrigan 2019-12-14T14:22:19.095Z

I was a bit confused by that too. As a beginner, reading some of the documentation can be hard to unpick

dharrigan 2019-12-14T14:23:12.096200Z

What does it mean that it stops at the function boundary?

alexmiller 2019-12-14T16:01:52.098700Z

The parking functions only work in a go macro because the go macro rewrites the code around it. So once you call into a function the go macro can no longer “see” it to do any rewriting

dharrigan 2019-12-14T16:53:51.100700Z

So, if I have something like this (go (if (pos? x) (anotherns/my-function x))), then what execution context will my-function have? In the sense of threads? On the same thread as the go-block, or elsewhere?

2019-12-14T17:00:29.102Z

The same as the go block, and if my-function does any blocking operations it will clog up the threadpool

dharrigan 2019-12-14T17:06:33.103100Z

understood about blocking, I'm trying to understand better, It's just that I'm trying to consoldate this "once you call into a function, the go macro...", with what happens when I call into a function, and how threads etc. are maintained/created

2019-12-14T17:09:14.104800Z

function boundary means if there's a fn form between go and a parking form, it's not considered to be part of it

2019-12-14T17:10:20.106Z

so e.g in the following form (go (fn [] (<! c))) the <! will not be rewritten, and thus is illegal

dharrigan 2019-12-14T17:12:20.106300Z

isn't <! async? why would it be parking?

2019-12-14T17:20:02.109400Z

parking operations are resolved at compile-time. if there's a function boundary between a parking operation and a go block, you can't know in advance the evaluation context, so the go macro just ignores it

dharrigan 2019-12-14T17:23:22.109800Z

Looks like I'll have to do more reading into the subject. Thank you! 🙂