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

Concurrency in Rust

doc.rust-lang.org

Post reply on HN
Print view View original

151–160 of 160 posts

Re: Concurrency in Rust

#151

Post by [deleted] »

lambda wrote: post #142
quotemstr wrote: post #138

Earlier quoted context omitted.

There's more to the world than end-user applications though. I think your mental model is that there are two kinds of Rust user: OS kernel writers and people who create applications with menu bars and save buttons. What about network services that would rather begin failing requests on overload than shut down entirely and restart, incurring potentially big delays in the process? What about scientific computing projec…

There's more to the world than end-user applications though. I think your mental model is that there are two kinds of Rust user: OS kernel writers and people who create applications with menu bars and save buttons. Not at all. I myself work with more types of applications than that; I work with high-reliability networked daemons, GUI applications, and web applications. What about network services that would rather be…

[deleted]

Re: Concurrency in Rust

#152

Post by nwmcsween »

quotemstr wrote: post #150
nwmcsween wrote: post #149

Earlier quoted context omitted.

You are arguing for replacing bad behavior "abort on OOM" with something even worse, exceptions. I honestly don't think you know what exceptions entail wrt what compilers do and the resulting bloat.

What, unwind tables? The ones that go untouched in normal operation? They're hardly catastrophic, and you need unwind support as a mandatory part of some ABIs in the first place. I know perfectly well what exceptions entail, and I maintain they're vastly better than other error handling strategies. You're the one who doesn't know what he's talking about.

You do understand it's usually in the ballpark of +20% or more to text or so that is in the loaded part of the program right? Also define mandatory, what requires eh_frame..?

Re: Concurrency in Rust

#153

Post by quotemstr »

nwmcsween wrote: post #152
quotemstr wrote: post #150

Earlier quoted context omitted.

What, unwind tables? The ones that go untouched in normal operation? They're hardly catastrophic, and you need unwind support as a mandatory part of some ABIs in the first place. I know perfectly well what exceptions entail, and I maintain they're vastly better than other error handling strategies. You're the one who doesn't know what he's talking about.

You do understand it's usually in the ballpark of +20% or more to text or so that is in the loaded part of the program right? Also define mandatory, what requires eh_frame..?

The Windows 64-bit ABI, for starters. The world is not Unix. As for additional text: compare that with the code spent on explicit checks of error values. You can't just enable exceptions on an existing codebase and point to how awful they are without account for the now-extraneous code that exception support allows you to remove.

Re: Concurrency in Rust

#154

Post by twic »

quotemstr wrote: post #79
steveklabnik wrote: post #77

Earlier quoted context omitted.

> No custom allocator can make the task gracefully report failure > instead of panicing. So, first of all, "custom allocators" means two things: * overloading the allocator that's used by liballoc, and the crates that depend on it, like libstd * other allocators entirely The first is described here: https://doc.rust-lang.org/book/custom-allocators.html And the second is still in RFCs: https://github.com/rust-lang/rfc…

> why is panic-ing bad, but an exception good? Because the Rust people don't believe in making "catch" a first-class primitive in the language, and in fact, fully support a runtime option to turn all panics into aborts. Even if abort-on-panic were to be killed as a legal mode of operation, and even if the stigma were to be removed from std::panic::recover, we'd still be left with a language with two error handling st…

There was a really interesting article on error handling in languages recently:

http://joeduffyblog.com/2016/02/07/the-error-model/

It makes the case that you do in fact want two different error handling mechanisms, because there are two quite different kinds of errors. The author argues that running out of memory is most practically treated as an unrecoverable error which aborts the process.

Re: Concurrency in Rust

#155

Post by Manishearth »

nitrogen wrote: post #147
Manishearth wrote: post #139

Earlier quoted context omitted.

> I do see the need to have a memory allocation approach that can handle OOM gracefully. Do you find anything wrong with inserting an allocator that panics on OOM (IIRC the default one aborts on OOM) and using `std::panic::recover` to catch the panic? This is the same as throwing and catching an exception. Note that `recover()` is designed to be exception safe by default. (There soon will be a way to make std heap AP…

I don't myself, no, but I haven't dived into Rust yet. I'm assuming that recovery can happen at a point where data can still be saved.

Yeah.

Re: Concurrency in Rust

#156

Post by steveklabnik »

nindalf wrote: post #146
steveklabnik wrote: post #37

Earlier quoted context omitted.

I am in the middle of working on a second draft of the book. This page is one of the oldest bits of docs, overall, and isn't my best work. It's not _wrong_, I just have very high personal standards. It was adapted from older documentation and was written in the time up to 1.0, where I had a LOT on my plate.

Thanks Steve, you're doing great work. Can't wait to read the book once its done!

Thanks! You can follow along with the progress here, if you're interested: https://github.com/rust-lang/book

Re: Concurrency in Rust

#157

Post by conceit »

catnaroek wrote: post #126
conceit wrote: post #121

Earlier quoted context omitted.

If thinking about ownership of orphaned data is horrible, that still doesn't mean that there is no general solution. I can't support your argument, because I'm not capable. If I was, I probably wasn't asking in the first place.

Let me interpret the situation in managed languages from a Rust programmer's lens: All managed resources are actually owned by the runtime, and merely borrowed by your program. Thus, killing threads is “safe”: no managed resource can possibly become orphaned. The result is very pleasant as long as your program only uses runtime-managed resources. But things quickly become hairy when you want to use foreign libraries…

Would seem silly to use rust for all it's safety features to then call into c libraries, anyhow. So much for Heartbleed wouldn't happen with rust.

Re: Concurrency in Rust

#158

Post by catnaroek »

conceit wrote: post #157
catnaroek wrote: post #126

Earlier quoted context omitted.

Let me interpret the situation in managed languages from a Rust programmer's lens: All managed resources are actually owned by the runtime, and merely borrowed by your program. Thus, killing threads is “safe”: no managed resource can possibly become orphaned. The result is very pleasant as long as your program only uses runtime-managed resources. But things quickly become hairy when you want to use foreign libraries…

Would seem silly to use rust for all it's safety features to then call into c libraries, anyhow. So much for Heartbleed wouldn't happen with rust.

> Would seem silly to use rust for all it's safety features to then call into c libraries, anyhow.

Why? One very important use case for Rust's unsafe sublanguage is making wrappers around C libraries that can be used in the safe sublanguage. If anything, using C libraries is more pleasant in Rust (or C++) than in managed languages, because you don't particularly need to accomodate or work around the idiosyncracies and quirks of a complex runtime system. That's pretty much the entire point of my above post (GP to this one).

> So much for Heartbleed wouldn't happen with rust.

You may not agree, but the position consistently taken by Rust is that, while avoiding unsafe code is highly desirable, it isn't always possible. What is always possible is to isolate unsafe code, so that, if the safety guarantees of the safe sublanguage are ever violated, you know what parts of your program to audit.

Re: Concurrency in Rust

#159

Post by mtanski »

qznc wrote: post #16
Manishearth wrote: post #13

Earlier quoted context omitted.

A failed malloc aborts the process. If this is important to you, don't use the heap abstractions in the stdlib then. This is no different from the situation in C++. (You can also plug in a custom allocator which behaves differently)

On Linux malloc never fails actually. Instead, the kernel kills processes if it runs out of memory.

You're correct in the way that it's default behavior, but the behavior can be turned off.

Also, if you're using cgroups (or anything that leverages that like containers) you can put a limit on the memory resource and then malloc will fail. Which is common enough, and only becoming more common as people are collocating a lot of disparate workloads on nodes (using the kurbenets scheduler).

Re: Concurrency in Rust

#160

Post by nwmcsween »

quotemstr wrote: post #153
nwmcsween wrote: post #152

Earlier quoted context omitted.

You do understand it's usually in the ballpark of +20% or more to text or so that is in the loaded part of the program right? Also define mandatory, what requires eh_frame..?

The Windows 64-bit ABI, for starters. The world is not Unix. As for additional text: compare that with the code spent on explicit checks of error values. You can't just enable exceptions on an existing codebase and point to how awful they are without account for the now-extraneous code that exception support allows you to remove.

the x86_64 psabi also requires eh_frame but it's actually not used for much except exceptions, stack unwinding, etc thus is mostly useless. Of course all of this is sort of moot with rust as rust requires eh_frame.. and the resulting bloat.
Post reply on HN