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

51–60 of 160 posts

Re: Concurrency in Rust

#51

Post by cyphar »

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.

Overcommit will fail if you go over the overcommit ratio. In addition, the process will die if you start using the fake pages the kernel gave you. But yes, malloc can fail on Linux.

Re: Concurrency in Rust

#52

Post by bluejekyll »

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

This is called from within a threads execution, right? I think the question is about being able to kill a thread externally.

Java had this in 1.0 or 1.1 and then thought better of it and deprecated the API.

Re: Concurrency in Rust

#53

Post by bluejekyll »

armitron wrote: post #50

This looks terribly overcomplicated/overengineered to me, to the point where I doubt many are going to adopt/switch to this style, esp when used to more convenient approaches [even the standard C++ approach, faulty as it may be]. Also note how much boilerplate one has to write and how the code snippets bypass error handling (do it differently in "real" code but don't show us how). Bleh.

Try it before you mock it.

This prevents boiler plate issues, and allows the compiler to help you discover threading issues at compile time rather than runtime.

It's easy enough to just mark all you structs send+sync and still shoot your foot off just like in any language. The point is, you need to be explicit that your trying to shoot your foot off, as opposed to other languages which basically pull the trigger for you.

Re: Concurrency in Rust

#54

Post by Manishearth »

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?

Note that this isn't exactly a safe operation, since a killed thread may stop in the midst of something. It's safer to have it process messages on a loop and include a quit message.

Re: Concurrency in Rust

#55

Post by felixgallo »

bluejekyll wrote: post #52
rdtsc wrote: post #36

Earlier quoted context omitted.

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

This is called from within a threads execution, right? I think the question is about being able to kill a thread externally. Java had this in 1.0 or 1.1 and then thought better of it and deprecated the API.

erlang also uses per-actor message queues and has a kill safe design philosophy, so it's not a problem.

Re: Concurrency in Rust

#56

Post by djhworld »

domenp wrote: post #5
djhworld wrote: post #4

I'm having a tough time trying to understand this snippet for i in 0..3 { thread::spawn(move || { data[i] += 1; }); } What is the 'move' thing here before the ||

A quick search turned up this: https://doc.rust-lang.org/book/closures.html#move-closures .

Great thanks.

Re: Concurrency in Rust

#57

Post by gregwebs »

masklinn wrote: post #47
gregwebs wrote: post #44

Earlier quoted context omitted.

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.

AFAIK combining killThread and bracket (or just about anything really) is fraught with issues[0] and hardly qualifies as clean. [0] http://blog.haskell-exists.com/yuras/posts/handling-async-ex...

Yes, there is still an issue with async exceptions when there is an exception during the cleanup handler of bracket. Probably this has not received the attention it deserves because fundamentally if a cleanup handler throws an exception you may well still have resource issues. But the article also proposes ways of solving this issue, so lets not give up on async exceptions.

Re: Concurrency in Rust

#58

Post by Manishearth »

armitron wrote: post #50

This looks terribly overcomplicated/overengineered to me, to the point where I doubt many are going to adopt/switch to this style, esp when used to more convenient approaches [even the standard C++ approach, faulty as it may be]. Also note how much boilerplate one has to write and how the code snippets bypass error handling (do it differently in "real" code but don't show us how). Bleh.

> overcomplicated/overengineered to me

You don't have to worry about most of this. Doing concurrent things in Rust is pretty clean. Designing new concurrent abstractions from scratch is where you need to worry about Send and Sync and be careful. And it's totally worth it, entire classes of concurrency errors just go away.

The error handling can get verbose, though with the new `?` operator and `catch` syntax it's much cleaner now.

Re: Concurrency in Rust

#59

Post by galonk »

steveklabnik wrote: post #37
nindalf wrote: post #2

I think Steve Klabnik could clarify this, but the book at that link is in the process of being rewritten. I think it might be good to wait until it is. I personally found it slightly difficult to follow compared to other options like the soon to be published Programming Rust.

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 obvious to you).

Not a criticism of the tutorial, but it does something common in Rust tutorials which is really a problem with the language at this point: Rust tutorials always spend a lot of time interpreting Rust's notoriously poor error messages (e.g. "what this message that doesn't mention Sync is trying to tell you is that you need Sync on this type"). That's great when you're doing the tutorial, but as soon as you're on your own man are those errors frustrating.

Re: Concurrency in Rust

#60

Post by masklinn »

bluejekyll wrote: post #52
rdtsc wrote: post #36

Earlier quoted context omitted.

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

This is called from within a threads execution, right? I think the question is about being able to kill a thread externally. Java had this in 1.0 or 1.1 and then thought better of it and deprecated the API.

> This is called from within a threads execution, right? I think the question is about being able to kill a thread externally.

Yes the GP has the wrong arity, exit/1 terminates the current process but exit/2[0] will send an exit signal to an other process and possibly cause them to terminate (depending on the provided Reason and whether they trap exits).

This is a normal behaviour of Erlang which enables things like seamless supervision trees, where exit signals propagate through the supervision trees reaping all of the processes until they encounter a process trapping exits and a supervisor can freely terminate its children[1]

This can work because erlang doesn't have shared state[2][3], and BEAM implements termination signaling (so processes can be made aware by the VM of the termination of other processes)

[0] http://erlang.org/doc/man/erlang.html#exit-2

[1] http://erlang.org/doc/design_principles/sup_princ.html#id740...

[2] between processes, state is always owned by specific processes and queried/copied out across the process boundary

[3] and thus a process being terminated can't leave inconsistent state behind for others to corrupt themselves (or the VM itself) with

Post reply on HN