apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Nairn" <steven.na...@googlemail.com>
Subject Re: Showstoppers to apr release(?)
Date Tue, 06 Nov 2007 13:05:31 GMT
William A. Rowe, Jr. wrote:
> William A. Rowe, Jr. wrote:
> > Here's my list of open issues which should probably be
> > determined before we roll out 1.2.x, I was hoping we were
> > further along than this on Unix in particular;
> >
> > * HP/UX 11.11i testatomic.c:288  Failed creating threads???
> >   Investigating, it happens to be the only testatomic failure
> >   (1/17).  Enabling the concurrency, which it appears we can,
> >   has no effect.
>
> No clue yet - if anyone has a box, help is appreciated.

Sorry for so long in getting around to this. I gave it a run
on our 11i box ("uname -r" gives B.11.11) and reproduced
that failure.

It's a pretty simple one - testatomic is running out of
threads. It appears that the default max threads per process
is 64 (specified in the kernel config file
/usr/conf/master.d/core-hpux). That is the value reported by
sysconf(_SC_THREAD_THREADS_MAX).

The problem is that test_atomics_threaded() tries to create
two times NUM_THREADS threads and NUM_THREADS is defined as
40. Therefore it tries to create 80 threads so
apr_thread_create() fails, returning APR_EAGAIN.

The "quick'n'dirty" fix is to decrease NUM_THREADS for HPUX
(attached patch).

In case someone's upped their max threads then a better
solution might be to take something like the minimum of 40
and half the value returned by sysconf(_SC_THREAD_THREADS_MAX).
That gets a bit tricky though as there are a couple of
arrays sized by NUM_THREADS. gcc doesn't mind
sizing automatic arrays with dynamic values but I imagine
HP's compiler might.

Cheers,
Steve Nairn

Mime
View raw message