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

[Nicolas George]

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.

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

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/f02999c6/attachment.sig>