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

[Matt Oliver]

On Thu, 23 Jan 2020 at 08:12, 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?


I actually had an old patch for that too. On Win32 the shutdown function
will cause any existing recv calls in other threads to instantly return
with an error code. I havnt tested the patch recently with current ffmpeg
master but it should serve as a proof of concept.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: avformat-udp-Enable-FIFO-when-using-windows-sockets.patch
Type: application/octet-stream
Size: 1486 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200123/1bb46021/attachment.obj>