Pier Fumagalli wrote: > "Cavan Morris" <[EMAIL PROTECTED]> wrote: > > >>Attached is an ASCII file with my build process. It may be important to not >>that I'm using the APR libraries from the webapp-module-1.0.2-tc402 and apxs >>from apache 2.0.32 not 2.0.35. > > > You _need_ to use the APR libraries shipped with your Apache 2.0 version, > and the same APXS, anyway it's bloated on my system as well. I have some > spare time on my hands tonight, and tomorrow... I'll try to revamp the > autoconf stuff and make it build again... > > <NOTE> > I might break something in Win32 builds. Can someone with MSVC give it a > go once they see my commits, please? > </NOTE> > >>Question: >>when you say "Yes, that's right... " do you mean yes that's right, the >>socketpool work may solve bug 8433 or yes that's right, it doesn't compile?
The #if APR_HAS_THREADS is wrong that should have been #if APR_HAS_ATOMIC. But APR_HAS_ATOMIC is not existing and it is not possible to force APR to use a generic C code for atomics (apr_force_atomic_generic cannot be set to one via some configure options). Therefore when apr_atomic_t is not defined mod_webapp compilation failed miserably. I will try to change the #if APR_HAS_THREADS into #ifdef USE_ATOMICS like in the mod_mem_cache.c of httpd-2.0. (As a temporary fix). > > > Both... Yeah, the socketpool solves that problem as well (at least it > should, what's your worker configuration in Apache 2.0? - output of httpd -l > please :) and yes, it doesn't compile... > > On APR they're talking about removing atomics, since those bits actually > depend (especially on sun hardware) on some opcodes present only on V9 > architectures (JF might explain it better than me, the only 2 RISCs I've > coded for are PPCs and MIPSes), thus making binaries unportable from one > architecture to another... The atomic for SPARC is using cas that is an 8+ opcode. This causes "problems" on SPARC machines with "old" processors. There is a C code for machines that does not have a as atomic support. > Therefore my thought is to rely on inter-process > mutex locking, instead of atomics)... > > >>Thanks for your time. > > > I feel lucky to have some spare time on my hands :) :) :) > > Pier > > >>-Cavan Morris >> >>----- Original Message ----- >>From: "Pier Fumagalli" <[EMAIL PROTECTED]> >>To: "Tomcat Developers List" <[EMAIL PROTECTED]> >>Sent: Saturday, April 27, 2002 8:58 AM >>Subject: Re: mod_webapp.so socketpool changes.. >> >> >> >>>"Cavan Morris" <[EMAIL PROTECTED]> wrote: >>> >>> >>>>Hey Guys, >>>>I reported bug 8433 and am looking for a way to solve it. I thought that >>>>the >>>>socketpool work you're doing might solve the problem but wasn't able to >>>>compile the latest from cvs. >>>>My question is do you think that what you're working on could fix the bug? >>>>This is a very severe problem on my system. I have to restart both apache >>>>and >>>>tomcat if I get 2 concurrent requests. If you've got any ideas on the java >>>>side I can look into it, but have no idea what to do with the C. >>> >>>Yes, that's right... Can you send out why it doesn't compile? That code uses >>>ATOMIC, but given that atomics are going to go away in a short time from >>>APR, we'll need to change it to use intra-process mutexes... >>> >>>It doesn't compile on OS/X as well... :( >>> >>> Pier >>> >>>-- >>>I think that it's extremely foolish to name a server after the current U.S. >>>President. B.W. Fitzpatrick >>> >>> >>> >>>-- >>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >>> >>> >>-- >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > I think that it's extremely foolish to name a server after the current U.S. > President. B.W. Fitzpatrick > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>