[FFmpeg-devel] [PATCH 3/3] avformat/udp: Enable FIFO when using windows sockets.

[Mark Thompson]

On 07/12/16 06:05, Matt Oliver wrote:
> Signed-off-by: Matt Oliver <protogonoi at gmail.com>
> ---
>  libavformat/udp.c | 19 +++++++++++++++++--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index f8c861d..0e4766f 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -64,6 +64,14 @@
>  #define HAVE_PTHREAD_CANCEL 0
>  #endif
> 
> +#if !HAVE_PTHREAD_CANCEL && (HAVE_THREADS && HAVE_WINSOCK2_H)
> +/* Winsock2 recv function can be unblocked by shutting down and closing
> the socket */

This seems dubious to me.  Can you explain how this can work reliably on Windows?

To offer some context, the reason that POSIX states that close() at the same time as any other operation is undefined is because it is impossible to avoid the following race:

Thread 1:
  Load the file descriptor
  Enter the recv() call in the standard library
  Get preempted just before entering the system call
Thread 2:
  Call close() on the file descriptor
  Finish closing, the file descriptor is now invalid and can be reused
Thread 3 (could be thread 2 again, or a hidden part of the implementation):
  Make a new file (with open() or similar)
  Get given the same file descriptor, reused
Thread 1:
  Start running again
  Actually make the recv() system call, which now refers to thread 3's file
  Data loss/crash/other badness

Since there is no way to determine that a thread is actually inside the system call rather than preempted immediately before it there is no way in POSIX to avoid the race.  An alternative implementation seeking to avoid this issue could perhaps supply such a function to determine the blocked state of another thread, or maybe file descriptors could be unique forever, but neither of these seems to apply in this case.

Thanks,

- Mark