3 ms·

The interface is different because if you use a green thread within a GC'd language, you can do anything -- change anything, interact with anything -- and nothi

The interface is different because if you use a green thread within a GC'd language, you can do anything -- change anything, interact with anything -- and nothing will crash. No locking involved, and no hidden locking under the hood. It's not meant to be a performance boost, but a way of writing code where "might this crash?" is a question you're never bothered to ask. It's wonderfully freeing. Not true of native threads. If a goroutine were replaced with a native thread, it would swiftly crash on GC.

theseoafs 11y ago
This is only true for n:1 green threading.
- sillysaurus3 11y ago
  Sure. But I might write my n:1 code more quickly, robustly, and performant than your m:n code, since m:n forces the programmer to carefully worry about whether their code will break.
  - theseoafs 11y ago
    Maybe, if my program has a lot of shared mutable state. I'm smart enough to avoid that though.
Veedrac 11y ago
We're talking pretty explicitly about Rust, which doesn't have that problem.
wtetzner 11y ago
> a way of writing code where "might this crash?" is a question you're never bothered to ask. Is that actually true? Yes, you won't get a partially written int, but you could still run into consistency issues if you don't lock. For example, if you need thread A to update both x and y to have a consistent state, and B is reading both x and y, A might update x, then the scheduler would switch to B, and be might read the new x and the old y. If the update A was making needed to update both x and y for the system to be in a consistent state, you have a problem.
- sillysaurus3 11y ago
  It will do what you just described. And what you described won't crash. If you use the int as an offset into raw memory, then sure, that will. But if you use it as an offset into a list, then it won't. At most it will cause an exception to be generated. That will cause the reader thread to die, because it was the code that caused the exception, but it still won't crash.
  - wtetzner 11y ago
    Right, but I don't really see how that's freeing. A crash isn't good, but having your program be incorrect might be even worse. If the program crashes, you know it. But it might take some time before you recognize that your logic is wrong, which might cause all kinds of damage. So I don't think it frees you from thinking about concurrency at all.

theseoafs 11y ago

This is only true for n:1 green threading.

sillysaurus3 11y ago
Sure. But I might write my n:1 code more quickly, robustly, and performant than your m:n code, since m:n forces the programmer to carefully worry about whether their code will break.
- theseoafs 11y ago
  Maybe, if my program has a lot of shared mutable state. I'm smart enough to avoid that though.

Veedrac 11y ago

We're talking pretty explicitly about Rust, which doesn't have that problem.

wtetzner 11y ago

> a way of writing code where "might this crash?" is a question you're never bothered to ask. Is that actually true? Yes, you won't get a partially written int, but you could still run into consistency issues if you don't lock. For example, if you need thread A to update both x and y to have a consistent state, and B is reading both x and y, A might update x, then the scheduler would switch to B, and be might read the new x and the old y. If the update A was making needed to update both x and y for the system to be in a consistent state, you have a problem.

sillysaurus3 11y ago
It will do what you just described. And what you described won't crash. If you use the int as an offset into raw memory, then sure, that will. But if you use it as an offset into a list, then it won't. At most it will cause an exception to be generated. That will cause the reader thread to die, because it was the code that caused the exception, but it still won't crash.
- wtetzner 11y ago
  Right, but I don't really see how that's freeing. A crash isn't good, but having your program be incorrect might be even worse. If the program crashes, you know it. But it might take some time before you recognize that your logic is wrong, which might cause all kinds of damage. So I don't think it frees you from thinking about concurrency at all.