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

[Matt Oliver]

On 3 December 2016 at 22:05, Nicolas George <george at nsup.org> wrote:

> Le tridi 13 frimaire, an CCXXV, Matt Oliver a écrit :
> > That was because the pthread wrappers dont set errno, so its a required
> > change to remove dependency on pthread.
>
> The pthread wrappers are supposed to match the pthread API, and it does
> not use errno: this change is needed by itself.
>
> > Your right i misread the use of ff_socket_nonblock so an extra change
> would
> > need to be added to set that to nonblocking instead. Theres already code
> > after the recv call that checks if any data was read back and just loops
> if
> > there wasnt any available which implements polling (should it be in
> > nonblocking mode). So thats why i assumed nonblocking was acceptable
>
> Looping is necessary in case of interrupted system calls; the code is
> overly careful by testing EAGAIN too.
>
> > Just out of curiosity why is polling considered unacceptable?
>
> It is awfully inefficient.
>
> If the polling interval is large, it adds latency to the processing. If
> it is short, it becomes a resource drain. Multimedia application often
> require low latency.
>
> You may think that a 100 Hz polling will have low latency enough for
> most uses and still be a negligible power drain, and thinking about PC
> applications you would probably be right. But think of a player on an
> embedded device reading a network stream that got interrupted. Since it
> is no longer playing, you do not pay attention to it, and you do not
> realize the player is still there, polling the network to see if it
> comes back. As a consequence, the CPU cannot enter deep-sleep state, and
> your battery in drained in a few hours.
>
> And of course, if someone were to just turn the socket non-blocking,
> since the loop does not have a timer in it, it becomes the ultimate form
> of polling evil: busy wait, and this is a terrible power drain even on
> huge PCs.
>
> FFmpeg uses polling all over the place, but fortunately, with just the
> UDP streams it can be entirely avoided. Eliminating all polling is
> amongst my long-term projects.
>

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.


>
> >  As i understand it pthread_cancel implements polling internally anyway
> as
> > any blocking function performed in the rx thread has to periodically
> check
> > the status of pthread_cancel to see if it has been set from another
> thread.
>
> I believe you are wrong. The core property of pthread_cancel(), which
> you can not emulate portably with other functions, is that it interrupts
> blocking system calls like recv(). It is implemented internally with
> non-portable notification techniques: a specific signal on Linux if I
> read correctly.


Again i was about to correct myself but you beet me to it.