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
..
executor	ts/executor: clear the reactor instead of closing it...	2022-09-13 07:29:50 +00:00
mod.rs	ts/timers: multiple improvements	2022-09-13 07:29:50 +00:00
pad.rs	ts/runtime: slight optimizations for sub tasks related operations	2022-08-18 18:42:18 +02:00
task.rs	ts/Task: don't drain sub tasks after state transition and iteration	2022-09-13 07:29:50 +00:00