You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was surprised to find that dataflow operators, such as map, accept a FnMut as argument. A FnMut is a function which can be mutated, which means it is called with a &mut self to itself. This seems like it would hinder parallelizing multiple calls to this function over multiple workers; conversely, if they are somehow cloned so that each worker mutates a different copy, this can be surprising if the author tried to rely on the mutating inner state.
Am I missing something?
The text was updated successfully, but these errors were encountered:
The dataflows that you construct with map are constructed thread-locally; there is no shared state unless you wrap that state with an Arc and maybe a Mutex if you would like to share it. Rust will prevent you from writing code that shares state between threads otherwise. The author maybe well be surprised if they expected only a single instance of map (and its closed-over state) to be created, but that would be a docs / teaching bug as it is 100% the design of the system to behave that way.
I was surprised to find that dataflow operators, such as
map
, accept aFnMut
as argument. AFnMut
is a function which can be mutated, which means it is called with a&mut self
to itself. This seems like it would hinder parallelizing multiple calls to this function over multiple workers; conversely, if they are somehow cloned so that each worker mutates a different copy, this can be surprising if the author tried to rely on the mutating inner state.Am I missing something?
The text was updated successfully, but these errors were encountered: