[FFmpeg-devel] [PATCH 4/4] avformat/udp: do not use thread cancellation when receiving data

[Hendrik Leppkes]

On Wed, Jan 22, 2020 at 10:12 PM Marton Balint <cus at passwd.hu> wrote:
>
>
>
> On Wed, 22 Jan 2020, Nicolas George wrote:
>
> > Marton Balint (12020-01-16):
> >> It is not supported by every threading implementation, and the only thing we
> >> gain with it is an immediate shutdown of receiving packets on close and
> >> avoiding the poll call before reading the data.
> >>
> >> I don't think it is a big issue if it takes 0.1 sec of delay to close an udp
> >> stream. Back when this was introduced the delay was 1 sec, which was indeed
> >> noticable.
> >
> > I don't like this. 0.1 s is less noticeable than 1 s for interactive
> > human users, but for applications it may be way too much.
>
> pthread_cancel is not implemented properly on Win32, also it is generally
> not considered a good practice. 0.1 sec delay is still the lesser evil
> than a lockup as shown in ticket #5717.
>
> An alternate approach might be to call shutdown() from the main thread and
> hope that this interrupts the recvfrom() call in the receiver thread. It
> tends to work for linux, I am not sure how other platforms would react,
> what do you think?
>

This is how it works without practical delay on Windows with
pthread_cancel as a noop right now. Calling closesocket() from the
main thread unblocks recvfrom calls with an error return, allowing the
thread to immediately close.
Not sure how reliable this is on other systems, but in Win32 it its
specifically documented to unblock waiting worker threads.

- Hendrik