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

Matt Oliver protogonoi at gmail.com
Sat Dec 3 11:34:33 EET 2016


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

> Le duodi 12 frimaire, an CCXXV, Matt Oliver a écrit :
> > Which changes would those be?
>
> The fix of errno / return value for pthread_cond_timedwait() for
> example.
>

That was because the pthread wrappers dont set errno, so its a required
change to remove dependency on pthread.


>
> >           This function is already set as nonblocking
>
> I think you read this specific part of the code wrong. Unfortunately,
> since this is a pivotal part of your reasoning, it ruins everything
> else.
>

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


>
> recv() can not be in non-blocking mode here because it would cause the
> whole thread to behave in busy-wait, which is completely unacceptable.
>

Just out of curiosity why is polling considered unacceptable?


>
> Remember that pthread_cancel() was introduced here to eliminate polling.
> Please do not bring it back. The way forward is to implement an event
> loop for all protocols.


 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.
So isnt this just removing the polling from ffmpeg and adding it back in
somewhere else anyway.


More information about the ffmpeg-devel mailing list