[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] fclose: avoid double close race when possible

From: Jim Meyering
Subject: Re: [PATCH] fclose: avoid double close race when possible
Date: Wed, 11 May 2011 10:56:31 +0200

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 present in close_fd_maybe_socket for calling closesocket()
> prior to _close(), but for all other platforms, we might as well be
> nice and avoid the race.
> * lib/fclose.c (rpl_fclose): Rewrite to avoid double-close race on

Good one.

> This patch is necessary to avoid a regression on libvirt on Linux.

Note to readers (I know Eric knows): the fclose replacement is necessary
because of a POSIX-noncompliance bug present even in the very latest glibc.

> 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 operations like the one in our fclose() wrapper?  Or do we
> just chalk up the race to the poor quality of mingw in the first
> place, since more compliant platforms don't have the race, and since
> the cost of replacing everything just to guarantee atomicity sounds
> like it would significantly slow down mingw execution.

If it's worth worrying about, the latter (below) sounds better.

> Or do we come up with some alternative on mingw that avoids the
> race?  Perhaps opening a temporary fd on /dev/null, then using
> dup2 to overwrite the fd underlying the file pointer after the
> fflush(), so that we can then use fclose() and expect success
> (since fclose is no longer operating on a socket fd) while still
> gracefully closing out the socket?  For that matter, does dup2()
> on mingw properly handle the case where the destination fd is
> an open socket?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]