Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Green threads explained in 200 lines of Rust

cfsamson.gitbook.io

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Green threads explained in 200 lines of Rust

#31

Post by verttii »

PopeDotNinja wrote: post #18
FullyFunctional wrote: post #14

Earlier quoted context omitted.

Funny enough we actually started prototyping with Erlang for subsequent project (which was cancelled before it went far). Unfortunately I don't know enough to know what's special about the Erlang scheduler (if anything), but as I understand the Erlang concurrency model, it's mostly about not sharing memory (forces explicit communication). That's obviously going to eliminate a host of bugs, but it would have been way…

Given that Erlang is sufficiently different from anything else I've seen, it doesn't surprise me that trying to be productive in Erlang before you knew it well enough was suboptimal experience. I like it, and more specifically Elixir, quite a bit, but the learning curve was steep.

It's fair to say Erlang's strength or appeal is not the language itself but the platform you instruct with it. That's also where the learning curve is.

Re: Green threads explained in 200 lines of Rust

#32

Post by cfsamson »

steveklabnik wrote: post #17
bluejekyll wrote: post #3

The explanation of the asm! macro is great, I’ve always been a little confused by it. It does make me thinking about how this could be useful in the context of Futures and async/await.

> It does make me thinking about how this could be useful in the context of Futures and async/await. At its core, when you pass a Future (really, a chain of futures, but in the end that's still a Future) to an executor, the executor creates a stack for it. An executor with multiple futures will then switch between them, sorta similar to the code seen here. The details depend on the exact executor, of course, but the…

The long term plan for this was/is to actually connect them to futures and the async story in rust, adapting this to be an executor and implementing our own futures (though I probably have to implement a simple reactor and fake some IO operation in e seperate thread as well). However, it's quite a bit of rework and better to seperate this in two parts, but I feel it could be a good way to build brick by brick towards a pretty good understanding for those interested.

Re: Green threads explained in 200 lines of Rust

#33

Post by kccqzy »

Great explanation! Although I have to wonder, why did the author choose to use Rust for this project? As far as I can see, it didn't really use any of Rust's advanced features not available in C or C++, like tagged unions, pattern matching, advanced type system, traits, borrow checking…

For what it's worth, I translated the whole code into C++. And it's essentially the same: https://gist.github.com/kccqzy/c404b8614f39f854f137dcc9284b0... And it runs correctly on macOS and Linux when compiled with clang.

Re: Green threads explained in 200 lines of Rust

#34

Post by nwallin »

mamcx wrote: post #27
amelius wrote: post #7

Earlier quoted context omitted.

Yeah, of course, but how would you work this type of code into something that can be used in production? The goal should be to have a green thread library that you can just use without thinking about registers or assembly.

Going for "toy" code to production ready is hard. Also, rust already have several options for concurrency/parallelism that are more idiomatic. The only reason I see is to have a coroutine library for build a language, yet I have wonder if I put a facade of Actix actors or similar for this case...

> Going for "toy" code to production ready is hard.

Too true. I recently implemented a feature, and I had a standalone working version 90% complete in a day or two. Getting the thing solid, tested, and integrated took the better part of a month.

Part of that, I think, is our education model. Every project I ever had in school was started from scratch, I worked on it for a short period of time, turned it in, and never looked at it again. I got really good at that. I can write a toy version of a hard problem in a very short period of time. But I'm terrible at integrating those things into a larger whole, and I know for a fact I'm not alone in this.

I think it's a huge problem that corporations think that a CS degree is job training and won't hire you if you haven't done it, but colleges think it's about abstract concepts and research and don't teach engineering principles.

Re: Green threads explained in 200 lines of Rust

#35

Post by kasane »

kccqzy wrote: post #33

Great explanation! Although I have to wonder, why did the author choose to use Rust for this project? As far as I can see, it didn't really use any of Rust's advanced features not available in C or C++, like tagged unions, pattern matching, advanced type system, traits, borrow checking… For what it's worth, I translated the whole code into C++. And it's essentially the same: https://gist.github.com/kccqzy/c404b8614f3…

Why would one pick C or C++ over Rust for this project?

Re: Green threads explained in 200 lines of Rust

#36

Post by sim_card_map »

kccqzy wrote: post #33

Great explanation! Although I have to wonder, why did the author choose to use Rust for this project? As far as I can see, it didn't really use any of Rust's advanced features not available in C or C++, like tagged unions, pattern matching, advanced type system, traits, borrow checking… For what it's worth, I translated the whole code into C++. And it's essentially the same: https://gist.github.com/kccqzy/c404b8614f3…

Thanks a lot for this!

Re: Green threads explained in 200 lines of Rust

#37

Post by sim_card_map »

kasane wrote: post #35
kccqzy wrote: post #33

Great explanation! Although I have to wonder, why did the author choose to use Rust for this project? As far as I can see, it didn't really use any of Rust's advanced features not available in C or C++, like tagged unions, pattern matching, advanced type system, traits, borrow checking… For what it's worth, I translated the whole code into C++. And it's essentially the same: https://gist.github.com/kccqzy/c404b8614f3…

Why would one pick C or C++ over Rust for this project?

Much easier to build, for me at least.

I tried installing Rust and building the example, but then it complained about nightly features, and I didn't have time to figure that out.

C/C++ are mainstream languages, and building is as simple as g++ test.cpp.

Re: Green threads explained in 200 lines of Rust

#38

Post by [deleted] »

chc4 wrote: post #28
amelius wrote: post #4

Isn't one downside that the inline assembly will not be peephole-optimized by the code generator (LLVM)? E.g., you'd be saving and restoring registers that are not even used.

Not really. You potentially don't know who is "resuming", and so don't know what registers they will clobber. It would only be a "downside" if 1) your code uses a register 2) no other possible green threads do, and that isn't an invariant any compiler I know will promise, especially in the face of FFI calls. If you're at the point where you want to do register allocation and spilling optimization across multitasking…

[deleted]

Re: Green threads explained in 200 lines of Rust

#39

Post by asdfasgasdgasdg »

_cbsz wrote: post #29

FWIW, there is POSIX-specified functionality (swapcontext and friends) for changing the user thread context: http://pubs.opengroup.org/onlinepubs/009695399/functions/swa...

It's very slow though, at least if you believe the Boost docs. They have various context-controlling types. One of them is called ucontext_t, and falls back to ucontext. Then there's fcontext_t, which is basically a more advanced version of this article. Boost's docs claim it is much faster than ucontext.
Post reply on HN