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

61–70 of 160 posts

Re: Concurrency in Rust

#61

Post by Manishearth »

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.

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 cases isn't close to a solution. No language or stdlib can solve this problem 100%.

At a baremetal level, it helps having this, but you're probably better off not using the stdlib anyway.

Re: Concurrency in Rust

#62

Post by steveklabnik »

galonk wrote: post #59
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.

It certainly is _confusing_ if not _wrong_. You silently add "move" to the closure without any mention or explanation (then later say "note that we're copying i" without explaining that you're talking about the "move" keyword). The bit about Mutex also has a "just type this to fix the problem with no explanation of how or why it works" flavour (although I guess if you already grok mutexes then its use here might be o…

Yeah, this is what I mean. So this was originally written before "move" or even any of the current closure implementation existed. And with so much to do, the focus was on making what existed accurate more than a holistic approach.

Furthermore, almost a year after 1.0, we have a lot better understanding of what people struggle with when trying to learn Rust, so we have a better idea of how to teach it.

Please file bugs for notoriously poor errors. We have put a lot of work into many of them, but there's a lot of ways to go. It seems like most people really like them or really hate them.

Re: Concurrency in Rust

#63

Post by m0th87 »

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.

Parallelism necessarily implies concurrency [1]

So, "SIMD concurrency" is not incorrect (although SIMD parallelism is more correct :)

1: http://programmers.stackexchange.com/a/155110

Re: Concurrency in Rust

#64

Post by Manishearth »

galonk wrote: post #59
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.

It certainly is _confusing_ if not _wrong_. You silently add "move" to the closure without any mention or explanation (then later say "note that we're copying i" without explaining that you're talking about the "move" keyword). The bit about Mutex also has a "just type this to fix the problem with no explanation of how or why it works" flavour (although I guess if you already grok mutexes then its use here might be o…

> Rust's notoriously poor error messages

I've actually heard the opposite feedback; Rust's error messages try to be super helpful.

Note that concepts like ownership and Sync are new to most programmers, and it's impossible to explain them in an error message. This is where the extended error messages (via --explain) and the book come in.

The tutorial has this style because Rust espouses catching things at compile time, so the tutorial demonstrates this being done by doing the wrong thing a few times and reiterating why it gave an error.

----

Could you give examples of confusing error messages? I'd love to improve them. The one you mention .... doesn't exist. This (http://is.gd/keukPm) is what that error message looks like, and (a) it mentions Sync, (b) it also mentions that `Arc` cannot be shared between threads safely.

If you were referring to "So, we need some type that lets us have more than one reference to a value and that we can share between threads, that is it must implement Sync." from the book, the last part about Sync has nothing to do with that error message. If you follow the book, the error message is clear without the context of threads -- `data` was moved into the first spawn() call and the subsequent ones can't use it. One does not conclude that Sync is necessary from this error message, and that's not what the book is trying to say.

This sentence is actually skipping a step, one like http://is.gd/RPNOm4, where the compiler asks you for a Send type (or a Sync type, depending on the exact code). Instead of stepping through this example, it just introduces Sync directly by noting that we're dealing with threads anyway and the reader already knows what Sync/Send are. It doesn't conclude that Sync is necessary from the error message.

> The bit about Mutex also has a "just type this to fix the problem with no explanation of how or why it works" flavour (although I guess if you already grok mutexes then its use here might be obvious to you).

The previous sentence says "for example a type that can ensure only one thread at a time is able to mutate the value inside it at any one time.", which is exactly what a mutex does. Unless you want a lower level explanation which IMO isn't necessary. It could explain locking more though; I'll fix that.

Re: Concurrency in Rust

#65

Post by jerf »

tonyhb wrote: post #42
IshKebab wrote: post #32

Earlier quoted context omitted.

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

You can use contexts to send a cancellation signal to goroutines: https://blog.golang.org/context . This is more of an implementation detail you make on a case-by-case language rather than a builtin to go.

That's not a way to "kill goroutines". That's a way to "ask goroutines to die when they get around to it." Useful, but a fundamentally different thing. Go does not have a way to kill goroutines, nor, per some of the other discussion in this thread, do I ever expect it to.

Re: Concurrency in Rust

#66

Post by thegenius2000 »

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?

Can you clarify what you mean by "kill goroutines?" Because my understanding was if you return while inside a goroutine it get's handled by the GC immediately, and (as someone else mentioned) you can use context to send deadlines/cancellation signals to go routines.

Re: Concurrency in Rust

#67

Post by Manishearth »

galonk wrote: post #59
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.

It certainly is _confusing_ if not _wrong_. You silently add "move" to the closure without any mention or explanation (then later say "note that we're copying i" without explaining that you're talking about the "move" keyword). The bit about Mutex also has a "just type this to fix the problem with no explanation of how or why it works" flavour (although I guess if you already grok mutexes then its use here might be o…

FWIW, I fixed some of these concerns here: https://github.com/rust-lang/rust/pull/32529

Re: Concurrency in Rust

#68

Post by pornel »

reycharles wrote: post #21
barosl wrote: post #15

Earlier quoted context omitted.

So, for those who may know JavaScript, you may have seen code like this: var closures = []; for (var i=0;i The code above will result in incorrect results: 5, 5, 5, 5, 5. Because you're capturing `i` as a reference. To avoid this, JS devs typically do this: closures.push((function(i) { return function() { console.log(i); }; })(i)); Or, if you can afford the ES6 support: for (let i=0;i Rust supports this pattern by a…

The ES6 "fix" is an abomination in my opinion. You're closing over a mutable variable, so you should see the mutations! IMO the real fix would be to write for (var i = 0; i In your ES6 solution if you e.g. increment "i" inside the loop after the closure the closure will see the mutation! The real cause of confusion is mutation and javascript's scoping rules.

ES6 fix is:

      for(let i = 0; i

Re: Concurrency in Rust

#69

Post by Manishearth »

thegenius2000 wrote: post #66
IshKebab wrote: post #32

Earlier quoted context omitted.

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

Can you clarify what you mean by "kill goroutines?" Because my understanding was if you return while inside a goroutine it get's handled by the GC immediately, and (as someone else mentioned) you can use context to send deadlines/cancellation signals to go routines.

The ability to kill an arbitrary goroutine from the outside. To use context you need to write your specific goroutine such that it checks for cancellation and will eventually handle a cancellation request. This cannot be done with an arbitrary goroutine.

Re: Concurrency in Rust

#70

Post by naasking »

m0th87 wrote: post #63
fndjdh wrote: post #9

Earlier quoted context omitted.

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.

Parallelism necessarily implies concurrency [1] So, "SIMD concurrency" is not incorrect (although SIMD parallelism is more correct :) 1: http://programmers.stackexchange.com/a/155110

This not true. CPUs have instruction parallelism, even on a single CPU, but there is no observable concurrency.

SIMD is data-level parallelism, not concurrency.

Post reply on HN