François Laignel d39aabe054 ts/Task: don't drain sub tasks after state transition and iteration ... Subtasks are used when current async processing needs to execute a `Future` via a sync function (eg. a call to a C function). In this case `Context::block_on` would block the whole `Context`, leading to a deadlock. The main use case for this is the `Pad{Src,Sink}` functions: when we `PadSrc::push` and the peer pad is a `PadSink`, we want `PadSrc::push` to complete after the async function on the `PadSink` completes. In this case the `PadSink` async function is added as a subtask of current scheduler task and `PadSrc::push` only returns when the subtask is executed. In `runtime::Task` (`Task` here is the execution Task with a state machine, not a scheduler task), we used to spawn state transition actions and iteration loop (leading to a new scheduler Task). At the time, it seemed convenient for the user to automatically drain sub tasks after a state transition action or an iteration. User wouldn't have to worry about this, similarly to the `Pad{Src,Sink}` case. In current implementation, the `Task` state machine now operates directly on the target `Context`. State transtions actions and the iteration loop are no longer spawned. It seems now useless to abstract the subtasks draining from the user. Either they transitively use a mechanism such as `Pad{Src,Sink}` which already handles this automatically, or they add substasks on purpose, in which case they know better when subtasks must be drained.		2022-09-13 07:29:50 +00:00
..
file	Update minimum supported Rust version to 1.63	2022-09-04 21:31:55 +03:00
fmp4	Update for GLib ParamSpec builder API changes	2022-09-05 11:45:47 +03:00
sodium	Update for GLib ParamSpec builder API changes	2022-09-05 11:45:47 +03:00
threadshare	ts/Task: don't drain sub tasks after state transition and iteration	2022-09-13 07:29:50 +00:00