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

when send_guard is disabled, Entry should not be Send? #191

Closed
skyzh opened this issue Mar 22, 2022 · 0 comments · Fixed by #202
Closed

when send_guard is disabled, Entry should not be Send? #191

skyzh opened this issue Mar 22, 2022 · 0 comments · Fixed by #202

Comments

@skyzh
Copy link

skyzh commented Mar 22, 2022

For any circumstances, we always unsafe impl Send and Sync for Entry:

dashmap/src/mapref/entry.rs

Lines 139 to 144 in afe293f

unsafe impl<'a, K: Eq + Hash + Send, V: Send, S: BuildHasher> Send for OccupiedEntry<'a, K, V, S> {}
unsafe impl<'a, K: Eq + Hash + Send + Sync, V: Send + Sync, S: BuildHasher> Sync
for OccupiedEntry<'a, K, V, S>
{
}

But within OccupiedEntry:

dashmap/src/mapref/entry.rs

Lines 133 to 137 in afe293f

pub struct OccupiedEntry<'a, K, V, S> {
shard: RwLockWriteGuard<'a, HashMap<K, V, S>>,
elem: (*const K, *mut V),
key: K,
}

We have a RwLockWriteGuard. This should not be Send if send_guard is not enabled.

Maybe we should add a feature gate over the unsafe impl of Send and Sync for OccupiedEntry?

Thanks for investigating into this in advance!

@skyzh skyzh changed the title when send_guard is disabled, Entry operations might be unsafe? when send_guard is disabled, Entry should not be Send? Mar 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant