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

71–80 of 160 posts

Re: Concurrency in Rust

#71

Post by catnaroek »

gregwebs wrote: post #30

Send + Sync are great. The downside of concurrency in Rust is: 1) There isn't transparent integration with IO in the runtime as in Go or Haskell. Rust probably won't ever do this because although such a model scales well in general, it does create overhead and a runtime. 2) OS threads are difficult to work with compared to a nice M:N threading abstraction (which again are the default in Go or Haskell). OS threads lea…

> There is no way to kill a thread in Rust

Think about the interaction with (non-memory) resource ownership. This is just horrible, and I wouldn't even want it in a higher-level language. If you want to carefully notify threads that they must terminate, set up a channel, or write to a shared variable, but please do not just forcibly terminate threads.

Re: Concurrency in Rust

#72

Post by z1mm32m4n »

fndjdh wrote: post #9
z1mm32m4n wrote: post #6

Does Rust have a way to work with SIMD concurrency as opposed to just fork/join concurrency? Something along the lines of how openmp or cilk let you do a parallel for all?

You seem to have concurrency confused with parallelism. Concurrency just means working on another task before the prior one has completed. You're describing parallelism which is doing multiple tasks at the same time.

By SIMD concurrency, I meant that I was curious about a construct that actually translated into simultaneously executing code, not just a construct that denotes work that "could" be done simultaneously.

Re: Concurrency in Rust

#73

Post by amluto »

IshKebab wrote: post #32
gregwebs wrote: post #30

Send + Sync are great. The downside of concurrency in Rust is: 1) There isn't transparent integration with IO in the runtime as in Go or Haskell. Rust probably won't ever do this because although such a model scales well in general, it does create overhead and a runtime. 2) OS threads are difficult to work with compared to a nice M:N threading abstraction (which again are the default in Go or Haskell). OS threads lea…

There's no way to kill goroutines either. In fact, are there any systems that allow you to cleanly kill threads?

POSIX has pthread_cancel. It's a big mess.

Re: Concurrency in Rust

#74

Post by bzbarsky »

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.

> On Linux malloc never fails actually.

Not true. For example, it can fail if there is no big enough chunk of virtual address space available (i.e. your heap is fragmented enough and your attempted allocation is big enough). I've even seen 64-bit processes manage to do this, my mmapping lots of multi-GB things at once and then trying to do large allocations.

Re: Concurrency in Rust

#75

Post by quotemstr »

Manishearth wrote: post #13
askyourmother wrote: post #8

What about the assumption (fatally flawed decision?) that malloc never fails when rust asks? Sounds like something that could affect concurrency

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)

No custom allocator can make a task that fails to allocate gracefully report an error. Rust's error handling design is just terrible, and mostly a consequence of eschewing exceptions.

Had Rust opted for exceptions, it'd be a much better, and actually usable, language. Rust's terribly error-handling strategy is the chief reason not to use it.

Re: Concurrency in Rust

#76

Post by quotemstr »

Manishearth wrote: post #61
qznc wrote: post #16

Earlier quoted context omitted.

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

A lot of folks are pointing out that malloc can fail, which is true, but the important part is that there are situations where your application will just abort randomly in the middle of nowhere (i.e. not during malloc) and there's nothing you can do about it. There are also situations where malloc fails and returns a null, but given the existence of situations with no errors on a malloc, handling the error in these c…

Bullshit. Every part of the C++ standard library (which is _much_ bigger than Rust's) can gracefully propagate resource exhaustion errors, including memory allocation failure, to callers. That Rust can't is a design flaw.

> there are situations where your application will just abort randomly

That's sure as hell not the case in any environment I choose to use.

Re: Concurrency in Rust

#77

Post by steveklabnik »

quotemstr wrote: post #75
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)

No custom allocator can make a task that fails to allocate gracefully report an error. Rust's error handling design is just terrible, and mostly a consequence of eschewing exceptions. Had Rust opted for exceptions, it'd be a much better, and actually usable, language. Rust's terribly error-handling strategy is the chief reason not to use it.

  > 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/rfcs/pull/1398

Both of these things are not yet stable. The second does, in fact, give you the ability to return an error code, by returning a Result.

However, on top of that, I don't see how

  >  mostly a consequence of eschewing exceptions.
and

  > No custom allocator can make the task gracefully report failure
  > instead of panicing.
Work together. Or rather, why is panic-ing bad, but an exception good?

Re: Concurrency in Rust

#78

Post by [deleted] »

steveklabnik wrote: post #77
quotemstr wrote: post #75

Earlier quoted context omitted.

No custom allocator can make a task that fails to allocate gracefully report an error. Rust's error handling design is just terrible, and mostly a consequence of eschewing exceptions. Had Rust opted for exceptions, it'd be a much better, and actually usable, language. Rust's terribly error-handling strategy is the chief reason not to use it.

> 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…

[deleted]

Re: Concurrency in Rust

#79

Post by quotemstr »

steveklabnik wrote: post #77
quotemstr wrote: post #75

Earlier quoted context omitted.

No custom allocator can make a task that fails to allocate gracefully report an error. Rust's error handling design is just terrible, and mostly a consequence of eschewing exceptions. Had Rust opted for exceptions, it'd be a much better, and actually usable, language. Rust's terribly error-handling strategy is the chief reason not to use it.

> 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 strategies and endless programmer confusion over which to use.

Rust's designers have done permanent damage to the language by not making exceptions the primary error reporting mechanism available to programmers, and it's not a mistake they can undo now.

Re: Concurrency in Rust

#80

Post by Manishearth »

quotemstr wrote: post #76
Manishearth wrote: post #61

Earlier quoted context omitted.

A lot of folks are pointing out that malloc can fail, which is true, but the important part is that there are situations where your application will just abort randomly in the middle of nowhere (i.e. not during malloc) and there's nothing you can do about it. There are also situations where malloc fails and returns a null, but given the existence of situations with no errors on a malloc, handling the error in these c…

Bullshit. Every part of the C++ standard library (which is _much_ bigger than Rust's) can gracefully propagate resource exhaustion errors, including memory allocation failure, to callers. That Rust can't is a design flaw. > there are situations where your application will just abort randomly That's sure as hell not the case in any environment I choose to use.

> can gracefully propagate resource exhaustion errors, including memory allocation failure, to callers

only on malloc. If the kernel overcommits, your process will abort when you try to use the memory, possibly way after the malloc and there's nothing you can do about it. That's the point being made here.

> That Rust can't is a design flaw.

(This is false, see Steve's reply above about this)

Post reply on HN