threadshare: ` test premature_shutdown` test sometimes timing out

Glad to see this test is still usefull! Will take a look ASAP

The test demonstrates a race condition using the pipeline TsAppSrc -> TsQueue -> TsAppSink with the following sequence:

Set the pipeline to Playing.
Push a buffer on TsAppSrc to initialize the Stream and wait for TsAppSink to pull the buffer.
Push a buffer on TsAppSrc.
Set the pipeline to Paused.
Irrelevant to this issue: make sure that pushing a buffer on TsAppSrc fails.
Set the pipeline back to Playing.
Wait for TsAppSink to pull the buffer from step 3.

Step 7 can hang if, in step 4, the TsAppSrc task loop is aborted before the buffer from step 3 is pulled from the internal channel receiver.

With previous design, I made sure that if we could push a buffer on TsAppSrc, it would not be lost due to a Pause.

Shall we keep this requirement or can we accept a buffer loss in that case?

Buffer loss is not acceptable, no :) When going to Ready yes, but no between Playing and Paused.

I thought so :) We will have to rework Task::cancel then. Do you want me to take a look at this?

That would be great, yes :) What do you want to rework there? Isn't the underlying problem here that we don't keep the channel around all the time between prepare and unprepare? Or is the problem that we get the buffer from the receiver of the channel and then we await on sending, then the future is cancelled and the buffer is gone?

I think it would make sense in appsrc to keep around a list of pending buffers from the receiver and make sure that the receiver lives for the whole prepare / unprepare lifecycle.

Yes you're right, we should keep the channel around and manage a flag to reject new buffers when appropriate. This would be closer to how DataQueue is designed I think.