[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: put_xlate_handle_node exception

From: Kevin Radke <kmradke_at_gmail.com>
Date: Wed, 15 Apr 2015 11:26:20 -0500

Philip,

I believe the non-portable-atomics flag is left over from getting 1.7
working due to the original APR bug. Since the bug is fixed, I'll try
without the flag and see what happens.

A make check for this apr also succeeds without any issues.

APR Lock Performance Test
==============

apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (UNNESTED) OK
    Starting 1 threads OK
microseconds: 24476 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (NESTED) OK
    Starting 1 threads OK
microseconds: 30257 usec
apr_thread_rwlock_t Tests
    Initializing the apr_thread_rwlock_t OK
    Starting 1 threads OK
microseconds: 42559 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (UNNESTED) OK
    Starting 2 threads OK
microseconds: 48643 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (NESTED) OK
    Starting 2 threads OK
microseconds: 49841 usec
apr_thread_rwlock_t Tests
    Initializing the apr_thread_rwlock_t OK
    Starting 2 threads OK
microseconds: 88017 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (UNNESTED) OK
    Starting 3 threads OK
microseconds: 71369 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (NESTED) OK
    Starting 3 threads OK
microseconds: 74264 usec
apr_thread_rwlock_t Tests
    Initializing the apr_thread_rwlock_t OK
    Starting 3 threads OK
microseconds: 156797 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (UNNESTED) OK
    Starting 4 threads OK
microseconds: 98064 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (NESTED) OK
    Starting 4 threads OK
microseconds: 99977 usec
apr_thread_rwlock_t Tests
    Initializing the apr_thread_rwlock_t OK
    Starting 4 threads OK
microseconds: 258812 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (UNNESTED) OK
    Starting 5 threads OK
microseconds: 122259 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (NESTED) OK
    Starting 5 threads OK
microseconds: 125806 usec
apr_thread_rwlock_t Tests
    Initializing the apr_thread_rwlock_t OK
    Starting 5 threads OK
microseconds: 344890 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (UNNESTED) OK
    Starting 6 threads OK
microseconds: 146183 usec
apr_thread_mutex_t Tests
    Initializing the apr_thread_mutex_t (NESTED) OK
    Starting 6 threads OK
microseconds: 149457 usec
apr_thread_rwlock_t Tests
    Initializing the apr_thread_rwlock_t OK
    Starting 6 threads OK
microseconds: 490974 usec
Trying proc mutexes with mechanism `default'...
  Mutex mechanism `default' is global in scope on this platform.
Trying global mutexes with mechanism `default'...
  no problems encountered...
Trying proc mutexes with mechanism `flock'...
  Mutex mechanism `flock' is not global in scope on this platform.
Trying global mutexes with mechanism `flock'...
  no problems encountered...
Trying proc mutexes with mechanism `sysvsem'...
  Mutex mechanism `sysvsem' is global in scope on this platform.
Trying global mutexes with mechanism `sysvsem'...
  no problems encountered...
Trying proc mutexes with mechanism `posix'...
  Mutex mechanism `posix' is global in scope on this platform.
Trying global mutexes with mechanism `posix'...
  no problems encountered...
Trying proc mutexes with mechanism `fcntl'...
  Mutex mechanism `fcntl' is not global in scope on this platform.
Trying global mutexes with mechanism `fcntl'...
  no problems encountered...
Trying proc mutexes with mechanism `proc_pthread'...
  Mutex mechanism `proc_pthread' is global in scope on this platform.
Trying global mutexes with mechanism `proc_pthread'...
  no problems encountered...
testatomic : SUCCESS

Kevin R.

On Wed, Apr 15, 2015 at 10:30 AM, Philip Martin <philip.martin_at_wandisco.com>
wrote:

> Kevin Radke <kmradke_at_gmail.com> writes:
>
> > I'm using --disable-nonportable-atomics and apr 1.5.1 compiled with gcc
> > 4.4.7.
> > httpd 2.2.29 is built with mpm=worker.
>
> Do you have a particular reason for using --disable-nonportable-atomics?
> I suspect it leads to code that is not used as often and thus less well
> tested. Perhaps try building apr without that setting.
>
> > make check in svn gives:
> > Summary of test results:
> > 1948 tests PASSED
> > 58 tests SKIPPED
> > 31 tests XFAILED (1 WORK-IN-PROGRESS)
> > SUMMARY: All tests successful.
>
> The APR regression tests probably exercise the atomic code more than the
> Subversion regression tests.
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*
>
Received on 2015-04-15 18:29:05 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.