mirror of
https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs.git
synced 2024-06-27 18:40:35 +00:00
The threadshare executor was based on a modified version of tokio which implemented the throttling strategy in the BasicScheduler. Upstream tokio codebase has significantly diverged from what it was when the throttling strategy was implemented making it hard to follow. This means that we can hardly get updates from the upstream project and when we cherry pick fixes, we can't reflect the state of the project on our fork's version. As a consequence, tools such as cargo-deny can't check for RUSTSEC fixes in our fork. The smol ecosystem makes it quite easy to implement and maintain a custom async executor. This MR imports the smol parts that need modifications to comply with the threadshare model and implements a throttling executor in place of the tokio fork. Networking tokio specific types are replaced with Async wrappers in the spirit of [smol-rs/async-io]. Note however that the Async wrappers needed modifications in order to use the per thread Reactor model. This means that higher level upstream networking crates such as [async-net] can not be used with our Async implementation. Based on the example benchmark with ts-udpsrc, performances seem on par with what we achieved using the tokio fork. Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/118 Related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/604
43 lines
1.3 KiB
Rust
43 lines
1.3 KiB
Rust
// Copyright (C) 2020-2021 François Laignel <fengalin@free.fr>
|
|
//
|
|
// Take a look at the license at the top of the repository in the LICENSE file.
|
|
|
|
//! Wrappers for the underlying runtime specific time related Futures.
|
|
|
|
use std::time::Duration;
|
|
|
|
use super::executor::Timer;
|
|
|
|
/// Wait until the given `delay` has elapsed.
|
|
///
|
|
/// This must be called from within the target runtime environment.
|
|
///
|
|
/// When throttling is activated (i.e. when using a non-`0` `wait`
|
|
/// duration in `Context::acquire`), timer entries are assigned to
|
|
/// the nearest time frame, meaning that the delay might elapse
|
|
/// `wait` / 2 ms earlier or later than the expected instant.
|
|
///
|
|
/// Use [`delay_for_at_least`] when it's preferable not to return
|
|
/// before the expected instant.
|
|
pub fn delay_for(delay: Duration) -> Timer {
|
|
Timer::after(delay)
|
|
}
|
|
|
|
/// Wait until at least the given `delay` has elapsed.
|
|
///
|
|
/// This must be called from within the target runtime environment.
|
|
///
|
|
/// See [`delay_for`] for details. This method won't return before
|
|
/// the expected delay has elapsed.
|
|
#[track_caller]
|
|
pub fn delay_for_at_least(delay: Duration) -> Timer {
|
|
Timer::after_at_least(delay)
|
|
}
|
|
|
|
/// Builds a `Stream` that yields at `interval`.
|
|
///
|
|
/// This must be called from within the target runtime environment.
|
|
pub fn interval(interval: Duration) -> Timer {
|
|
Timer::interval(interval)
|
|
}
|