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

Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem

bitbashing.io

Post reply on HN
Print view View original

41–47 of 47 posts

Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem

#41

Post by api »

Ygg2 wrote: post #39
aw1621107 wrote: post #35

Earlier quoted context omitted.

Differently how? And perhaps more importantly, what tradeoff(s) would those differences entail?

Green threads/Virtual threads are one solution, but then you need to ship a runtime for them, then you pay for what you don't use. Or don't standardize on them and have a split ecosystem of half libs supporting use `green-thread.rs` and the other half supporting `rust-gthreads`.

I wonder if you could have hidden green threads from the application entirely. Have a "full" standard library where std::thread is M:N green threads and I/O is implemented behind the scenes that way, and a "thin" version where std::thread is OS threads and I/O is just passed through to the OS. (Then of course no_std for embedded.)

Of course the problem then would be that Rust makes it trivially easy to call C code. As soon as someone in a green thread runtime called libc I/O functions directly they'd be in for a weird surprise when the call froze all threads on their worker.

Of course the "full" M:N runtime could be instrumented to print a warning when this occurs unless explicitly told not to, and std::thread in the "full" stdlib could allow explicit creation of full OS threads outside the runtime.

There is an attempt at doing this out there:

https://github.com/Xudong-Huang/may

Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem

#42

Post by aw1621107 »

api wrote: post #41
Ygg2 wrote: post #39

Earlier quoted context omitted.

Green threads/Virtual threads are one solution, but then you need to ship a runtime for them, then you pay for what you don't use. Or don't standardize on them and have a split ecosystem of half libs supporting use `green-thread.rs` and the other half supporting `rust-gthreads`.

I wonder if you could have hidden green threads from the application entirely. Have a "full" standard library where std::thread is M:N green threads and I/O is implemented behind the scenes that way, and a "thin" version where std::thread is OS threads and I/O is just passed through to the OS. (Then of course no_std for embedded.) Of course the problem then would be that Rust makes it trivially easy to call C code. A…

> Have a "full" standard library where std::thread is M:N green threads and I/O is implemented behind the scenes that way, and a "thin" version where std::thread is OS threads and I/O is just passed through to the OS. (Then of course no_std for embedded.)

That sounds vaguely like what Rust used to have with its I/O functions before its green thread implementation was removed [0]? Not sure it's quite the same thing, though:

> In today's [2014] Rust, there is a single I/O API -- std::io -- that provides blocking operations only and works with both threading models. Rust is somewhat unusual in allowing programs to mix native and green threading, and furthermore allowing some degree of interoperation between the two.

> [snip]

> In this setup, libstd works directly against the runtime interface. When invoking an I/O or scheduling operation, it first finds the current Task, and then extracts the Runtime trait object to actually perform the operation.

> On native tasks, blocking operations simply block. On green tasks, blocking operations are routed through the green scheduler and/or underlying event loop and nonblocking I/O.

[0]: https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...

Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem

#43

Post by aw1621107 »

Ygg2 wrote: post #39
aw1621107 wrote: post #35

Earlier quoted context omitted.

Differently how? And perhaps more importantly, what tradeoff(s) would those differences entail?

Green threads/Virtual threads are one solution, but then you need to ship a runtime for them, then you pay for what you don't use. Or don't standardize on them and have a split ecosystem of half libs supporting use `green-thread.rs` and the other half supporting `rust-gthreads`.

> Green threads/Virtual threads are one solution, but then you need to ship a runtime for them, then you pay for what you don't use.

Indeed, and IIRC that's one of the reasons Rust removed its green thread implementation in the first place.

> Or don't standardize on them and have a split ecosystem of half libs supporting use `green-thread.rs` and the other half supporting `rust-gthreads`.

Don't forget the third lib for abstracting over the two!

Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem

#44

Post by steveklabnik »

api wrote: post #41
Ygg2 wrote: post #39

Earlier quoted context omitted.

Green threads/Virtual threads are one solution, but then you need to ship a runtime for them, then you pay for what you don't use. Or don't standardize on them and have a split ecosystem of half libs supporting use `green-thread.rs` and the other half supporting `rust-gthreads`.

I wonder if you could have hidden green threads from the application entirely. Have a "full" standard library where std::thread is M:N green threads and I/O is implemented behind the scenes that way, and a "thin" version where std::thread is OS threads and I/O is just passed through to the OS. (Then of course no_std for embedded.) Of course the problem then would be that Rust makes it trivially easy to call C code. A…

May has soundness issues around TLS. You can cause undefined behavior in safe code. They do not plan on changing that (and I'm not sure it's even possible) but there's no way that it will become super popular due to this issue.

(and yes, as my sibling commentor mentions, Rust tried this before. Doesn't mean nobody can do it, but I suspect that it is not possible.)

Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem

#45

Post by lmm »

timeon wrote: post #37
lmm wrote: post #18

Earlier quoted context omitted.

> If the author wanted an explanation for a technical decision, they could open an issue and have a conversation like an adult. Opening an issue comes across as a whole lot more aggressive to me. That implies that they owe you an explanation or you want them to change their code. > They cry about the existence of some unsafe code, but don’t actually put in the effort to figure out if it can lead to a real problem lik…

> The key benefit of Rust is supposed to be better memory safety than C; if everything is using unsafe, why bother? Is Hyper all contained inside unsafe block? As far as I know it is not. So even if there is some unsafe code it is not same as writing it in C.

Apparently even quite basic things like splitting a string are done in unsafe code. So it sounds like while it may not be 100% unsafe, most of it is.

Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem

#46

Post by dang »

nindalf wrote: post #24
mrkline wrote: post #22

Earlier quoted context omitted.

Turns out we regularly play flight sims together on weekends, but didn't know about each others' software misadventures - small world, isn't it? If the reason I blogged about my coding hobby was to "get my 15 minutes on HN", I would be a deeply unhappy person.

[flagged]

You broke the site guidelines badly and repeatedly in this thread, for example in your aggressive comments to the article author, and in https://news.ycombinator.com/item?id=39139646 which was really totally unacceptable.

This is not cool.

You're a good contributor, and I appreciate that you don't do this all the time, but we've also had to warn you multiple times about this kind of thing in the past. If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.

Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem

#47

Post by dang »

nindalf wrote: post #31
lmm wrote: post #29

Earlier quoted context omitted.

[flagged]

You have no idea what you’re talking about. You’re so confidently incorrect about Rust that there’s no point even trying to educate you. Good day.

Please don't post like this. We have to ban such accounts and I don't want to ban you.

See https://news.ycombinator.com/item?id=39173369 for more.

Post reply on HN