Concurrency in Rust

Post by [deleted] » Sun, Mar 27, 2016, 1:54 PM UTC

rdtsc wrote: post #36

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?

Yes. In Erlang: exit(kill). or exit(Pid,kill). Will kill a process. It has an isolated heap, so it won't affect other (possibly hundreds of thousands of) running processes. That memory will be garbage collected, safely and efficiently. This will also work in Elixir, LFE and other languages running on the BEAM VM platform. EDIT: masklinn user below pointed out correctly, the example is exit/2, that is exit(Pid,kill).…

Post by the_why_of_y » Sun, Mar 27, 2016, 2:07 PM UTC

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?

Post by masklinn » Sun, Mar 27, 2016, 2:17 PM UTC

kentosi wrote: post #18

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…

Thanks for the explanation, but how would the move keyword know that you're referring to the i variable? Ie - what is there were multiple variables (such as a for loop with j in there)? Wouldn't it have been a better approach to add some sort of demarkation, such as i* or i^ (or whatever) to indicate this? Just curious.

Post by masklinn » Sun, Mar 27, 2016, 2:24 PM UTC

gregwebs wrote: post #44

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?

Yes. In Haskell you use `killThread` which throws an asynchronous exception to the thread. It is certainly difficult to perfectly cleanup resources in the face of asynchronous exceptions. However, once there are functions available to help you with this (e.g. use a bracket function whenever using resources) it becomes tractable. This functionality is critical to being able to timeout a thread.

Post by steveklabnik » Sun, Mar 27, 2016, 2:49 PM UTC

masklinn wrote: post #45

kentosi wrote: post #18

Earlier quoted context omitted.

Thanks for the explanation, but how would the move keyword know that you're referring to the i variable? Ie - what is there were multiple variables (such as a for loop with j in there)? Wouldn't it have been a better approach to add some sort of demarkation, such as i* or i^ (or whatever) to indicate this? Just curious.

> Wouldn't it have been a better approach to add some sort of demarkation, such as i* or i^ (or whatever) to indicate this? That's the path C++ took[0], the Rust people thought it had too much syntactic and semantic overhead, and that having just "move" and "referring" closures would be much simpler. If you want to mix them up, it's easy enough to create references outside the closure (and capture them by value with…