Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fn vs FnMut in operators #341

Open
amosonn opened this issue Nov 8, 2020 · 1 comment
Open

Fn vs FnMut in operators #341

amosonn opened this issue Nov 8, 2020 · 1 comment

Comments

@amosonn
Copy link

amosonn commented Nov 8, 2020

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?

@frankmcsherry
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants