Am 18.04.2017 um 00:16 schrieb Yann Ylavic:
Thanks Rainer for the detailed report (as usual).
On Mon, Apr 17, 2017 at 2:01 PM, Rainer Jung <rainer.j...@kippdata.de> wrote:
c) Failure to compile apr on Solaris 8
--------------------------------------
Using gcc 4.1.2 compiling locks/unix/proc_mutex.c:
In function 'proc_mutex_pthread_create':
607: error: lvalue required as left operand of assignment
In function 'proc_mutex_pthread_acquire_ex':
711: error: lvalue required as left operand of assignment
790: warning: implicit declaration of function 'pthread_mutex_timedlock'
In function 'proc_mutex_pthread_release':
868: error: lvalue required as left operand of assignment
In function 'proc_mutex_pthread_cond_create':
945: error: lvalue required as left operand of assignment
Concerning pthread_mutex_timedlock: that platform has
HAVE_PTHREAD_CONDATTR_SETPSHARED set to 1 but HAVE_PTHREAD_MUTEX_TIMEDLOCK
is not defined (and pthread_mutex_timedlock not available). So
APR_USE_PROC_PTHREAD_MUTEX_COND is defined. So in line 688 we enter the
"#else" branch which ends in line 815. That code includes a call to
pthread_mutex_timedlock.
Concerning the "lvalue required as left operand of assignment" the lines are
always of the form
proc_pthread_mutex_cond_locked(SOME_MUTEX) = SOME_INT;
and proc_pthread_mutex_cond_locked(m) is defined as
((m)->pthread_refcounting ? proc_pthread_cast(m)->cond_locked : -1)
which indeed doesn't look like a good lvalue.
Sorry about that, I thought I had tested the
APR_USE_PROC_PTHREAD_MUTEX_COND case with some #undef's on Linux but
it seems I missed it for my latest changes.
All the above hopefuly fixes with r1791718 and r1791728, both
backported to 1.6.x.
Sorry to say that, but there's now another strange test result on
Solaris 8. Again testprocmutex. It fails or mech "default_timed" in
test_exclusive here:
209 rv = apr_proc_mutex_unlock(proc_lock);
210 APR_ASSERT_SUCCESS(tc, "unlock after timedlock check", rv);
211
212 *x = 0;
213
214 for (n = 0; n < CHILDREN; n++)
215 make_child(tc, -1, &child[n], p);
216
217 for (n = 0; n < CHILDREN; n++)
218 await_child(tc, child[n]);
^^^^^^^^^^^
In await_child while waiting for the number 0 child, apr_proc_wait
returns after 75 seconds with code 1.
When I try t use truss, I had to terminate it after a few minutes,
because it wasn't terminating by itself. I had about half 550.000
lwp_mutex_lock and 590.000 lwp_mutex_unlock for each of the the 6
threads, and also about 40.000 per thread of:
lwp_cond_wait(0xFF040018, 0xFF040000, 0xFFBEF868) Err#62 ETIME
Any idea what to look for in the condvar impl of the timedlock feature?
Regards,
Rainer
