threadshare: Using abortable and AbortHandle to stop the task loop leads to a large delay in the main thread.

Using abortable and AbortHandle to stop the task loop leads to a large delay in the main thread.

When a share-thread element (ts-udpsrc/ts-udpsink/ts-jitterbuffer) changes state from Pause to Ready, it calls stop on its task. The task has an abort_handle, so it calls abort. And then, it sends a trigger Stop to the state machine and then waits for ACK from it.

At the state machine, the spawn_loop is stopped by aborting, and the trigger event Stop is put into pending_triggering_evt. At the run method, the event Stop is handled and the state machine sends ack to the main thread. The main thread receives ack and continues its job.

The problem is the main thread is blocked for a while by waiting for the ack from another thread via the abort handle method. The abortable is in futures::future::{self, abortable, AbortHandle, Aborted, BoxFuture, RemoteHandle};. As described in AbortHandle, we can stop a task from a remote future loop by calling its method abort. In the document, the method abort will not immediately stop the task:

Notifies the Abortable task associated with this handle that it should abort. Note that if the task is currently being polled on another thread, it will not immediately stop running. Instead, it will continue to run until its poll method returns.

In fact, the delay is about 0.0077s. In my case, there are 6 share thread elements in a pipeline (two flows, each flow contains ts-udpsrc, ts-udpsink, ts-jitterbuffer). Changing state of the pipeline gets 0.0462s. When my app handles 500 concurrent calls, the 500th must wait for 23s. It is not reasonable to block the main thread to wait for that.

0:00:23.062971436 25144      0x2216600 DEBUG             ts-runtime generic/threadshare/src/runtime/executor.rs:123:gstthreadshare::runtime::executor: Blocking on new dummy context
0:00:23.062986630 25144      0x2216600 TRACE             ts-runtime generic/threadshare/src/runtime/task.rs:649:gstthreadshare::runtime::task: Awaiting ack for Stop
0:00:23.070756777 25144 0x7f56d4001c60 TRACE             ts-runtime generic/threadshare/src/runtime/task.rs:1069:gstthreadshare::runtime::task: Task loop aborted
0:00:23.070809003 25144 0x7f56d4001c60 TRACE             ts-runtime generic/threadshare/src/runtime/executor.rs:558:gstthreadshare::runtime::executor: Task TaskId(2) on context src_ctx done
0:00:23.070894543 25144 0x7f56d8001d30 TRACE             ts-runtime generic/threadshare/src/runtime/task.rs:807:gstthreadshare::runtime::task: State machine popped TriggeringEvent { trigger: Pause }

From the log above, we can see the different time from "Awaiting ack for Stop" to "Task loop aborted" is about 0.0077s