bug-gnulib
[Top][All Lists]
Advanced

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

double _close()?


From: Gisle Vanem
Subject: double _close()?
Date: Tue, 12 Oct 2021 14:02:56 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

I've been trying to speed-up a 'diff -r dir1 dir2'
by disabling the "no-throw" stuff for MSVC/clang-cl:
  MSVC_INVALID_PARAMETER_HANDLING == SANE_LIBRARY_HANDLING

(suspecting it imposes some overhead. Maybe MSVC's
__try/__catch has lower overhead?)

But building with 'SANE_LIBRARY_HANDLING' crashes in
several places presumably because (in fclose.c):

#if WINDOWS_SOCKETS
  /* Call the overridden close(), then the original fclose().
     Note about multithread-safety: There is a race condition where some
     other thread could open fd between our close and fclose.  */
  if (close (fd) < 0 && saved_errno == 0)
    saved_errno = errno;

  fclose_nothrow (fp); /* will fail with errno = EBADF,
                          if we did not lose a race */
---------

the 'fp' associated with the 'fd' got closed.

I did this to fix it:

--- a/fclose.c 2021-06-10 12:59:56
+++ b/fclose.c 2021-10-12 13:43:18
@@ -79,9 +79,11 @@
   /* Call the overridden close(), then the original fclose().
      Note about multithread-safety: There is a race condition where some
      other thread could open fd between our close and fclose.  */
-  if (close (fd) < 0 && saved_errno == 0)
+  result = close (fd);
+  if (result < 0 && saved_errno == 0)
     saved_errno = errno;

+  /* If the above 'close()' succeeded, don't close the associated 'fp' again. 
*/
+  if (result)
     fclose_nothrow (fp); /* will fail with errno = EBADF,
                             if we did not lose a race */
----------------

Does this make sense? Or are we discouraged to
disable this TRY/CATCH stuff?

--
--gv



reply via email to

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