apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: 1.6.0 release candidates
Date Tue, 18 Apr 2017 14:25:03 GMT
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.jung@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


Mime
View raw message