Live data from Hacker News

Green threads explained in 200 lines of Rust

cfsamson.gitbook.io

41–48 of 48 posts

Re: Green threads explained in 200 lines of Rust

#41
post #35

Earlier quoted context omitted.

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.

Using nightly features is as simple as inserting +nightly as the first argument to rustc or cargo (assuming rust was installed with rustup, which is the default way to install it).

So in this case, it's just `rustc +nightly green_threads.rs`

Re: Green threads explained in 200 lines of Rust

#43
post #35
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?

If the point is to explain how green threads work, it is better to use a common language so people can simply try to understand the concept and not try to understand both the concept and the language at the same time.

Re: Green threads explained in 200 lines of Rust

#44

Co-routines are very useful and likely underused, but sometimes you are actually better off being able to pass the control to a given thread directly, other than having a scheduler involved. Anecdote: almost a decade ago, I was responsible for an NVMe-like implementation (hard- and software). The 3rd version of the firmware recognized the various components as threads, but there was no need for preemption (which woul…

There was some work to give linux this functionality via a switchto* family of syscalls. https://youtu.be/KXuZi9aeGTw

Anyone who thinks that a kernel system call is the way to do this basically doesn't get the concept.

Re: Green threads explained in 200 lines of Rust

#46

I feel like "200 lines of Rust" is a little misleading considering how much explaination there is. It's like saying you can learn all of string theory in 0 lines of Python.

it seems like in every post there's a naysayer about something. you're complaining about an article that explains a difficult topic extensively and generously - in my day you had to pay really really good money for that. who cares if the title focuses one aspect of the explanation? sure it's a little deceptive but it's such a minor cost to you that you literally spent more time complaining than they deceived you out (click link with false notion, see length, close page). LPT: being critical in and of itself does not make you look smart.

Re: Green threads explained in 200 lines of Rust

#47

Earlier quoted context omitted.

If you have any knowledge of it, what are your thoughts about the Erlang scheduler & Erlang's concurrency model?

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…

Unfortunately I don't know enough to know what's special about the Erlang scheduler (if anything)

Bon appetit: :-)

Appetizer (blog post):

http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-...

Entree (book chapter):

https://blog.stenmans.org/theBeamBook/#CH-Scheduling

Re: Green threads explained in 200 lines of Rust

#48
post #13

Part of the code is: unsafe { std::ptr::write(stack_ptr.offset(SSIZE - 16) as *mut u64, hello as u64); ctx.rsp = stack_ptr.offset(SSIZE - 16) as u64; gt_switch(&mut ctx, &mut n); } Only the last line should be unsafe — the first line appears to be writing in bounds to a Vec, which is easy (and much more readable) in safe Rust. Linux used to do its actual context switch in C with inline asm, and it changed to being in…

>Linux used to do its actual context switch in C with inline asm, and it changed to being in straight asm a while back.

Could you be a bit more specific, maybe a link to the diff e.g. THANKS!

Post reply on HN