Am 24.08.2018 um 23:41 schrieb Nick Kew:
On Fri, 24 Aug 2018 09:16:54 -0400
Eric Covener <cove...@gmail.com> wrote:

Starting a new thread as potential RM's may be filtering bugzilla
emails.

There are a lot of reports of PR62644 from solaris users of httpd, can
anyone RM?

You've spurred me into reviewing changes in svn since last release.
There seems to be not much to see other than the fix for the
solaris poll problem.

There's quite a bit more in trunk (some of it annoyingly
not labelled in commit messages).  I've gone briefly through
that and see no obvious backports.  Anyone else?

Some inconsistencies between trunk / 1.7 and 1.6 seen by looking at file_io/win32/buffer.c but the original commits also touch other files:

% diff -u apr/apr/trunk/file_io/win32/buffer.c apr/apr/branches/1.6.x/file_io/win32/buffer.c --- apr/apr/trunk/file_io/win32/buffer.c 2018-08-25 15:05:20.124591000 +0000 +++ apr/apr/branches/1.6.x/file_io/win32/buffer.c 2018-07-28 15:35:43.382858000 +0000
@@ -23,7 +23,7 @@
 {
     apr_status_t rv;

-    if (file->flags & APR_FOPEN_XTHREAD) {
+    if (file->mutex) {
         apr_thread_mutex_lock(file->mutex);
     }

@@ -31,7 +31,7 @@
         /* Flush the existing buffer */
         rv = apr_file_flush(file);
         if (rv != APR_SUCCESS) {
-            if (file->flags & APR_FOPEN_XTHREAD) {
+            if (file->mutex) {
                 apr_thread_mutex_unlock(file->mutex);
             }
             return rv;
@@ -52,7 +52,7 @@
             file->buffered = 0;
     }

-    if (file->flags & APR_FOPEN_XTHREAD) {
+    if (file->mutex) {
         apr_thread_mutex_unlock(file->mutex);
     }

Introduced by r1808457 and 1829962. The first one also touches file_io/win32/open.c and file_io/win32/readwrite.c in similar ways.

Then:

% diff -u apr/apr/branches/1.6.x/file_io/win32/buffer.c apr/apr/branches/1.7.x/file_io/win32/buffer.c --- apr/apr/branches/1.6.x/file_io/win32/buffer.c 2018-07-28 15:35:43.382858000 +0000 +++ apr/apr/branches/1.7.x/file_io/win32/buffer.c 2017-09-25 20:18:21.000000000 +0000
@@ -23,17 +23,13 @@
 {
     apr_status_t rv;

-    if (file->mutex) {
-        apr_thread_mutex_lock(file->mutex);
-    }
+    apr_thread_mutex_lock(file->mutex);

     if(file->buffered) {
         /* Flush the existing buffer */
         rv = apr_file_flush(file);
         if (rv != APR_SUCCESS) {
-            if (file->mutex) {
-                apr_thread_mutex_unlock(file->mutex);
-            }
+            apr_thread_mutex_unlock(file->mutex);
             return rv;
         }
     }
@@ -52,9 +48,7 @@
             file->buffered = 0;
     }

-    if (file->mutex) {
-        apr_thread_mutex_unlock(file->mutex);
-    }
+    apr_thread_mutex_unlock(file->mutex);

     return APR_SUCCESS;
 }


I think that's due to some unfinished work by Jean-Frederic. See related but probably unfinished discussions on r1834513.

Regards,

Rainer

Reply via email to