Hi Eric,
> Is it worth thinking about replacing _every_ standard function on
> mingw that can possibly create an fd in another thread (obviously,
> as an optional module, only needed in multithreaded gnulib clients),
> by grabbing a mutex to thus guarantee atomicity around otherwise
> racy operati
Eric Blake wrote:
> Calling close(fileno(fp)) prior to fclose(fp) is racy in a
> multi-threaded application - some other thread could open a new file,
> which is then inadvertently closed by the fclose that we thought
> should fail with EBADF. For mingw, this is no worse than the race
> already pr
Calling close(fileno(fp)) prior to fclose(fp) is racy in a
multi-threaded application - some other thread could open a new file,
which is then inadvertently closed by the fclose that we thought
should fail with EBADF. For mingw, this is no worse than the race
already present in close_fd_maybe_sock
