[vlc-devel] [PATCH] video_output: explicit vlc_testcancel

[Rémi Denis-Courmont]

Le keskiviikkona 26. helmikuuta 2020, 16.34.09 EET Quentin Chateau a écrit :
> Thanks for the hindsight, I dug further:
> 
> vlc_cond_timedwait is called, and so is pthread_cond_timedwait. The
> issue happens when the deadline parameter is in the past: when this
> happens, pthread_cond_timedwait does not act as a cancellation point
> anymore...

pthread_cond_timedwait() and pthread_cond_wait() are *always* cancellation 
points. The deadline does not matter.

vlc_cond_timedwait() and vlc_cond_wait() are likewise supposed to always be 
cancellation points. By my count, there are 21 outstanding vlc_cancel() call 
sites still depending on that behaviour.

Right now, there is a bug for which I just sent a patch

> In my case deadline happens to be in the past because
> ThreadDisplayPicture keeps failing (due to one of my video filters
> failing on the last frame)
> 
> I could not find this behavior in the pthread documentation, but it
> seems to be the case anyway. Do you think that we need to:
> 
>  1. Fix vlc_cond_timedwait so it will check for cancellation if the
>     deadline is in the past

I don't think that that's a feasible option.

For a start, I couldn't find that bug in those circumstances. I did find a bug 
with the same symptions in different circumstances though, see patch.

And then, even if the bug were there where I could not see it, there are no 
ways to determine that the deadline is in the past, as that changes 
asynchronously.

>  2. Acknowledge the fact that vlc_cond_timedwait is not always a
>     cancellation point and fix the issue higher in the stack, either in
>     vout_control_Pop, or similarly to the patch I sent, directly in Thread

You can't do that either, or at least not yet. Not when we still have 21 or so 
code paths depending on it.

-- 
Rémi Denis-Courmont
http://www.remlab.net/