(Again, for the list.)
Pressing pause, thanks for the heads up.
AFAIK this is the last of open(?) issues. I'll dig deeper into this
Monday... If anyone in EU has hints scribbled down somewhere please share.
Thanks for (re-)raising!
On Sun, Sep 2, 2018, 03:43 Rainer Jung <rainer.j...@kippdata.de> wrote:
> I think the following, especially the part about 1834513 is still
> unhandled.
>
> Regards,
>
> Rainer
>
> Am 25.08.2018 um 15:22 schrieb Rainer Jung:
> > 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
>
