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

fix: don't hang when sharepolicies return immediately #74

Merged
merged 1 commit into from
Nov 28, 2024

Conversation

alexjg
Copy link
Collaborator

@alexjg alexjg commented Nov 28, 2024

Problem: when using a SharePolicy (rather than doing some asynchronous work) it was possible for the repo to hang. The symptom of this would be that a repo would never respond to sync messages for a document when a SharePolicy returned a positive response for the document.

Why was this happening? When the repo first receives a sync message for a (document, peer) combination it checks whether the SharePolicy allows synchronization with the peer in question. To do this the repo creates a new future (correspoinding to SharePolicy::should_sync) and then puts it in a list of share decisions to poll. The share decisions are then polled on the next run through the event loop. If the repo is in a very quiet loop then no new event occurs to trigger the first poll of the future.

Solution: at the end of the repo event loop check if there are any share decisions to poll. If there are, then run the loop again.

Problem: when using a SharePolicy (rather than doing some asynchronous
work) it was possible for the repo to hang. The symptom of this would be
that a repo would never respond to sync messages for a document when a
SharePolicy returned a positive response for the document.

Why was this happening? When the repo first receives a sync message for
a (document, peer) combination it checks whether the SharePolicy allows
synchronization with the peer in question. To do this the repo creates a
new future (correspoinding to SharePolicy::should_sync) and then puts it
in a list of share decisions to poll. The share decisions are then
polled on the next run through the event loop. If the repo is in a very
quiet loop then no new event occurs to trigger the first poll of the
future.

Solution: at the end of the repo event loop check if there are any share
decisions to poll. If there are, then run the loop again.
@alexjg alexjg merged commit a5b19f7 into main Nov 28, 2024
8 checks passed
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.

1 participant