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?
Thanks,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
