François Laignel 8b54c3fed6 ts/Task: split iterate into try_next and handle_item ... Previous Task iteration model suffered from the following shortcomings: - When an iteration was engaged it could be cancelled at await points by Stop or Flush state transitions, which could lead to inconsistent states. - When an iteration was engaged it could not be cancelled by a Pause state transition so as to prevent data loss. This meant we couldn't block on the Pause request because the mechanism couldn't guarantee Paused would be reached in a timely manner. This commit split the Task iteration into: - `try_next`: this function returns a future that awaits for a new iteration to begin. The regular use case is to return an item to process. The item can be left to `()` if `try_next` acts as a tick generator. It can also return an error. This function can be cancelled at await points when a state transition request occurs. - `handle_item`: this function is called with the item returned by `try_next` and is guaranteed to run to completion even if a transition request is received. Note that this model plays well with the common Future cancellation pitfalls in Rust.		2022-08-10 20:02:53 +02:00
..
executor	threadshare: Fix some new clippy beta warnings	2022-08-10 12:58:28 +03:00
mod.rs	ts/executor: replace tokio with smol-like implementation	2021-12-25 11:25:56 +00:00
pad.rs	Update to gst::_log_macro_	2022-02-21 20:50:01 +01:00
task.rs	ts/Task: split iterate into try_next and handle_item	2022-08-10 20:02:53 +02:00
time.rs	ts/executor: replace tokio with smol-like implementation	2021-12-25 11:25:56 +00:00