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

Method for differentiating new broadcasters/queues #45

Open
schielb opened this issue Aug 31, 2023 · 1 comment
Open

Method for differentiating new broadcasters/queues #45

schielb opened this issue Aug 31, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@schielb
Copy link
Contributor

schielb commented Aug 31, 2023

In the sound branch, I'm adding a new broadcaster for pygame.mixer. In the current setup, all broadcasters pull from the same output_queue from the demo that is currently running. That queue has no way of differentiating strings that are passed into it. This leaves the individual broadcaster to parse through the message and determine if it is an item to "broadcast".

Ideally, we should have alternate ways for a user creating a demo to control which broadcaster is receiving its info.

@schielb schielb added the enhancement New feature or request label Aug 31, 2023
@schielb
Copy link
Contributor Author

schielb commented Aug 31, 2023

There are multiple ways we could try and do this. Two specific ones are:

  • Sub-queues: the output_queue could have different sub-queues that the demo creator needs to differentiate between
  • Sentinel values: Currently, every input to the output_queue.put method is going to be a string. We can inform the demo creator to put a sentinel value to start the string, something like "INFO " and "SOUND ", or so forth.

Predictably, there are pros and cons to both.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant