Skip to content

Fixed race condition on Win poll #45

Open
Andrepuel wants to merge 2 commits intolibp2p:masterfrom
Andrepuel:main
Open

Fixed race condition on Win poll #45
Andrepuel wants to merge 2 commits intolibp2p:masterfrom
Andrepuel:main

Conversation

@Andrepuel
Copy link
Copy Markdown

Fixes #44

Two arcs and one Box were all merged into one single Pin<Box<>> by using a self referential structure.

Also, a dynamic dyspatch as removed in favor of using generics
It was possible that a thread would read resync as false before another thread set it to true and subsequently register a waker after the other thread set resync to true and already tried calling AtomicWaker::wake().

To fix this issue, we first register the waker, and only then we check the resync value. If resync is true and we didn't have to register the waker, we just take it back.
@Andrepuel
Copy link
Copy Markdown
Author

Fixed cargo fmt

Copy link
Copy Markdown
Member

@jxs jxs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, thanks for this and sorry for delay!
Looking into the comment you left on the issue

Registering the Waker before loading resync would fix this issue, with the added side of effect of possible spurious wakes. However, spurious wakes should always be expected when dealing with Future. Another approach, would be to have both resync and waker inside a mutex, then we can read resync and set the waker on the same critical area.

I think the simplest solution would probably be to just have resync be a Mutex (we can register the Waker with it locked).
This would avoid all these unsafe uses right?
Thanks

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

Successfully merging this pull request may close these issues.

Possible race condition on Windows platform causing task to never wake

2 participants