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
Implement Watcher #2
Comments
Remaining subtask at creation of this issue is the final implementation of process |
@kwiesmueller has started working. Visit this issue on Issuehunt |
@0maxxam0 funded this issue with $1. Visit this issue on Issuehunt |
After spending the night on this, the process implementation is done, but due to some problems that arose with our tests in the subscription concept for both battleye and the watcher I started overthinking how this was built which might result in drastical changes to the subscription implementation or even an entire rewrite of watcher reducing the need of locks a lot. Updating this issue with further insights and probably a commit after some hours of sleep. #7 is the related "Bugfix" issue |
@0maxxam0 funded this issue with $2. Visit this issue on Issuehunt |
The last push to master solved many problems related to this. Next step is plugging it with OSProcess, testing it in a running example and then finish up the feature with more refactoring. |
Aside from that, Watcher implementation seems complete. |
@kwiesmueller has rewarded $2.10 to @kwiesmueller. See it on IssueHunt
|
Key part of gorcon is to start and manage a games process and restart it if necessary.
This functionality is placed under the internal name "watcher" as the job of this package is to watch a process and monitor it's state implying actions on special events (which might also be external commands).
Implementation of this package should be very generic as usual and offer key functionality for starters.
This means opening an interface for starting, stopping and keeping processes alive.
Acceptance Criteria:
Due to the general approach we follow with gorcon, event subscriptions should be handled by channels broadcasting all received process events to the subscribers.
This allows us to attach any kind of listener and allow them to act based on those events through the public API exposed by the watcher.
The text was updated successfully, but these errors were encountered: