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

Modifying InputProcessor system for greater reliability #174

Open
CRImier opened this issue May 10, 2019 · 0 comments
Open

Modifying InputProcessor system for greater reliability #174

CRImier opened this issue May 10, 2019 · 0 comments

Comments

@CRImier
Copy link
Member

CRImier commented May 10, 2019

Right now, a single app that doesn't keep an InputProcessor thread running is capable of bringing ZPUI down completely. This is because the app InputProcessors are also responsible for global callbacks, so if the thread is stopped/busy, a global callback (more important than anything the app could be doing) will not be processed until that happens. To fix that (and allow the user to i.e. switch to ZeroMenu and then to the main menu), we could probably add one more, the most basic, thread, which would receive the key data first and then re-send it to the input thread that's currently active. We can also probably limit these keypresses to ContextSwitch actions and tie them into, say, the receive_key processing code (as soon as ContextSwitch actions are implemented, check #42 ). Then, we need to test the end result and see how it fares against an intentionally mis-written app.

@CRImier CRImier added bug help wanted reliability good first issue New contributors should be able to tackle this labels May 10, 2019
@CRImier CRImier removed the good first issue New contributors should be able to tackle this label May 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant