11–20 of 160 posts
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?
What about the assumption (fatally flawed decision?) that malloc never fails when rust asks? Sounds like something that could affect concurrency
What about the assumption (fatally flawed decision?) that malloc never fails when rust asks? Sounds like something that could affect concurrency
(You can also plug in a custom allocator which behaves differently)
What about the assumption (fatally flawed decision?) that malloc never fails when rust asks? Sounds like something that could affect concurrency
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 ||
var closures = [];
for (var i=0;iTo avoid this, JS devs typically do this:
closures.push((function(i) {
return function() {
console.log(i);
};
})(i));
for (let i=0;iWhat 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)
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.
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 ||
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…
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.
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.
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.