[FFmpeg-devel] [PATCH 2/2] avformat/udp: Replace use of pthread_cancel.
george at nsup.org
Sat Dec 3 13:33:34 EET 2016
Le tridi 13 frimaire, an CCXXV, Matt Oliver a écrit :
> I was just writing an email to rephrase but you beet me to it (sorry i
> wasnt faster)
> I should rephrase this to "Why is polling with an acceptable timeout/sleep
> not acceptable". Obviously a event based callback would be more efficient
> but wouldnt setting an appropriate recv timeout then checking for thread
> exit before looping the recv call be an acceptable compromise. The thread
> exit check is minimal and if not set it would just go back into the
> blocking recv until data is received or the timeout triggers again. Long
> term callbacks would be better but would this be acceptable short term.
What would you consider an appropriate timeout, more precisely?
First, I would like to remind you that you cannot block with a timeout,
you would have to rework the code to use the ill-named poll(), which
would bring it back to its state before the use of pthread_cancel().
You are right that it would take care of the latency problem of the
network side, and allow a long timeout. But the latency is a problem too
for the cancellation. We had a 3 seconds timeout, users did get
impatient and interrupted it forcefully.
Furthermore, the core of your argument is that "the thread exit check is
minimal", but as I explained, it is not on embedded devices: anything
except "block until the kernel wakes up" is too much because it prevents
deep sleep states and drains the battery.
Modern operating systems allow multi-peer applications to work in a
completely poll-free completely notification-based way. FFmpeg, based on
very old code without global design, is quite far from achieving that.
But moving away from that is definitely moving in the wrong direction.
I assume you are not working just on a general distaste about
pthread_cancel(): you have in mind a specific platform in mind where it
is not available and you need the UDP thread, have you not?
Then I suggest working for that platform: find a way of implementing a
poll-free delay-free interruption mechanism. Maybe using non-portable
properties of the platform (like closing on another thread like Hendrik
evoked) or an entirely different API.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Digital signature
More information about the ffmpeg-devel