undefined | Better HN

0 pointscogman104y ago0 comments

Terminology mostly :D

I've not looked into the goroutine implementation, so I couldn't tell you how it compares to what I've read loom is doing.

Loom is looking to have some extremely compact stacks which means each new "virtual thread" as they are calling them will end up having bytes worth of memory allocated.

Another thing coming with loom that go lacks is "structured concurrency". It's the notion that you might have a group of tasks that need to finish before moving on from a method (rather than needing to worry about firing and forgetting causing odd things to happen at odd times).

0 comments

jayd164y ago

>structured concurrency

That's good to hear. You see a lot of these Loom discussions talk about implicit and magical asynchronous execution. I was afraid fine grained thread control would be left out. Its super useful if you want to interface with how most GUI frameworks function (ie a Main thread), or important OS threads like a thread with a bound GL context or what have you.

cogman10OP4y ago

Yeah, while virtual threads are the bread and butter of Loom, they are also adding a lot of QoL things. In particular, the notion of "ScopedVariables" will be a godsend to a lot of concurrent work I do. It's the notion of "I want this bit of context to be carried through from one thread of execution to the next".

Beyond that, one thing the loom authors have suggested is that when you want to limit concurrency the better way to do that is using concurrency constructs like semaphores rather than relying on a fixed pool size.

ccday4y ago

Not sure if it counts as structured concurrency but Go has the feature you describe: https://gobyexample.com/waitgroups

j / k navigate · click thread line to collapse