Philip, So far the build without the --disable-nonportable-atomics flag seems to working much better with httpd 2.2.29, svn 1.8.13, and apr 1.5.1. I'm no longer seeing the assert when using the worker mpm on a heavily loaded multi-core system.
Thanks! Kevin R. On Wed, Apr 15, 2015 at 11:26 AM, Kevin Radke <kmra...@gmail.com> wrote: > 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.mar...@wandisco.com> wrote: > >> Kevin Radke <kmra...@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* >> > >
