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

TMM: Multiqueue support #603

Closed
Askaholic opened this issue Jun 4, 2020 · 0 comments · Fixed by #644
Closed

TMM: Multiqueue support #603

Askaholic opened this issue Jun 4, 2020 · 0 comments · Fixed by #644
Assignees
Milestone

Comments

@Askaholic
Copy link
Collaborator

Add the ability for a player to join multiple matchmaker queues at the same time.

  1. Make sure that when a player finds a match, all other searches that the player is a part of are cancelled.
  2. Make sure that only one queue can run the matchmaking algorithm at a time. This might "just work" without changing anything, or it might need an mutex because of asyncio.
@Askaholic Askaholic added this to the Matchmaker milestone Jun 4, 2020
@Askaholic Askaholic self-assigned this Aug 25, 2020
Askaholic added a commit to Askaholic/server that referenced this issue Oct 4, 2020
Askaholic added a commit to Askaholic/server that referenced this issue Oct 7, 2020
Askaholic added a commit to Askaholic/server that referenced this issue Oct 11, 2020
Askaholic added a commit that referenced this issue Oct 28, 2020
* Generalize inform_player to work for any rating type

* Refactor matchmaker queue to report new matches via a callback

* Ensure that players can only be matched once at a time

* Rename inform_player

* Cleanup typing for Player

* Add integration test for multiqueueing

* Adjust default timeout

* Add another test for searches being cancelled

* Initialize locks lazily

It seems that during class creation time, the event loop that is automatically
detected by asyncio.Lock is not the same event loop that ends up being used
by asyncio.run. Therefore, when two coroutines try to access the lock at the
same time and one of them needs to await it, a RuntimeError is raised because
of mismatched event loops.

* Add SpinLock for synchronizing find_matches

This bypasses event loop issues like no loop existing at import time and
multiple event loops during tests.

* Condense overload type signatures

* Don't send "search_info: stop" for queues that succesfully find a match

* Clean up message sending

Use write_message, and avoid NoneType errors

* Refactor read_until_command to handle any number of message keys

* Ensure that player state is reset when matches time out

* Don't cancel underlying future if wait_for times out
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant