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

FuturesUnordered has an incorrect Sync impl #2050

Closed
okready opened this issue Jan 24, 2020 · 4 comments · Fixed by #2054
Closed

FuturesUnordered has an incorrect Sync impl #2050

okready opened this issue Jan 24, 2020 · 4 comments · Fixed by #2054
Labels

Comments

@okready
Copy link
Contributor

okready commented Jan 24, 2020

FuturesUnordered switched to using Cell for interior mutability of the len and head_all fields in 47f3ccb, but it still currently retains a Sync implementation. Since there isn't any synchronization performed when these fields are modified when calling the push method, the Sync implementation is invalid and should be dropped.

It looks like this was mentioned in #1669, but was overlooked in the actual commit.

okready added a commit to okready/futures-rs that referenced this issue Jan 24, 2020
FuturesUnordered was previously modified to use interior mutability for
the len and head_all fields using Cell, but its Sync implementation was
left intact. This implementation is no longer valid, so it has been
removed.

Fixes rust-lang#2050.
@cramertj
Copy link
Member

Good catch! I'd be happy to accept a PR introducing atomics to handle this case correctly, as discussed in #2051.

@okready
Copy link
Contributor Author

okready commented Jan 28, 2020

#2054 has a couple variations on a solution. There are some shortcomings to both, mostly with regards to how to deal with providing the appropriate length for iterators, so there may be another solution that's more suitable.

@tmiasko
Copy link
Contributor

tmiasko commented Jan 29, 2020

IMHO it would make sense to reconsider if having Sync for FuturesUnordered
is actually useful, independently of fixing the UB itself.

Currently in FuturesUnordered there is no separation between object that is
used to spawn additional futures into it, and object that is used for polling.
Since polling requires unique access, it means there is little room to actually
take advantage of Sync without introducing other form of synchronization.

@cramertj
Copy link
Member

Currently in FuturesUnordered there is no separation between object that is
used to spawn additional futures into it, and object that is used for polling.
Since polling requires unique access, it means there is little room to actually
take advantage of Sync without introducing other form of synchronization.

Yes, it was not intended for FuturesUnordered to be Sync. One option would be to remove the Sync bound, but that is a semver breaking change and so would have to be part of a new release that wouldn't be automatically available by current users. I think it's important to provide current users with an upgrade that provides soundness without including breaking changes.

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