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

[Tokio migration] Refactor AudioFileFetch #658

Conversation

Johannesd3
Copy link
Contributor

Refactors AudioFileFetch using async/await (more details in the commit message). Furthermore, fetch.rs was split in two files.

@Johannesd3 Johannesd3 force-pushed the refactor-audio-file-fetch branch 2 times, most recently from 6a9f295 to 325bc18 Compare February 28, 2021 14:36
@sashahilton00
Copy link
Member

There is a bigger question as to what we're going to do with audio file fetching in the long term. I'm part way through writing up some of the changes and moves away from Hermes to HTTP, and part of that is the move to the CDN, which pretty much every Spotify client uses now.

@Johannesd3 Johannesd3 mentioned this pull request Mar 8, 2021
13 tasks
@Johannesd3 Johannesd3 force-pushed the refactor-audio-file-fetch branch from 325bc18 to 3dcbe9d Compare March 11, 2021 17:06
Previously, polling `AudioFileFetch` consisted of three parts: Handling
stream loader commands, handling received data, and triggering preloading
in stream mode when the number of open requests is sufficiently small. The
first steps use channels which are polled, and if something's available,
it's handled. The third step is executed on every call of `poll`.

The first two could easily be refactored using a `tokio::select!`-loop.
Therefore, counting the number of open requests was also refactored to fit
into this scheme. They were previously counted using a shared
`AtomicUsize`. Now, the number of open requests is stored exclusively in
`AudioFileFetch`, increased on starting a request, and decreased by an
oneshot channel that is fired when a request is finished.

This allows us to `select` that channel in the loop too, and since
loading ahead makes only sense if the number of open requests decreases,
the third step is only executed in this case.

`AudioFileFetch` does not implement `Future` anymore, but is rather used
as helper struct in an async fn `audio_file_fetch`.
@Johannesd3 Johannesd3 force-pushed the refactor-audio-file-fetch branch from 3dcbe9d to ca255c1 Compare March 11, 2021 17:10
@sashahilton00
Copy link
Member

We'll merge this for now, as it is neater nonetheless.

@sashahilton00 sashahilton00 merged commit 963d50e into librespot-org:tokio_migration Mar 17, 2021
@Johannesd3 Johannesd3 deleted the refactor-audio-file-fetch branch March 28, 2021 14:10
This was referenced Apr 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants