[FFmpeg-devel] [PATCH 2/2] avformat/udp: Replace use of pthread_cancel.

[Nicolas George]

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)

No problem.

> 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.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161203/d1082bc7/attachment.sig>