Thread model and error handling cleanup #30
No reviewers
Labels
No Label
hex-grid
maintenance
music-player
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: savanni/monorepo#30
Loading…
Reference in New Issue
No description provided.
Delete Branch "refactoring/music-tokio"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Here I'm cleaning up the thread model and the error handling.
Error handling was pretty straightforward. I am making a better effort to propogate error conditions and then provide them in the API, when appropriate. Additionally, the client library is now able to handle them when they arrive, although it does nothing beyond printing the error message to the console.
The thread model is more complicated. I'm trying to reduce the complexity that I was creating by delegating things to Tokio, but it turns out that doesn't make sense in most cases. So, now, the core is not a thread at all. Instead it keeps a handle to the scanner thread. That thread is still a standard thread, as it is not asynchronous and is intended to run every minute until the application is shut down.
Playback, however, is now a tokio task. Core will keep hold of a playback controller, which manages that task. The controller will be instantiated for a track. When a new track starts playing, or a stop request arrives, the Core will tell the controller to abort the task before starting to play a new one.
Resolves:
4f47bcd9c3
to40cce7ce00