[vlc-devel] [PATCH] video_output: explicit vlc_testcancel
remi at remlab.net
Wed Feb 26 20:46:52 CET 2020
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
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
> 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.
More information about the vlc-devel