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

[Marton Balint]

On Thu, 23 Jan 2020, Matt Oliver wrote:

> 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 tested this on Windows7/10 and it does not seem to work. closesocket() 
indeed aborts the pending recv() call, but not shutdown(). CancelIoEx() 
seems to work though.

Regards,
Marton