Hi,
I'm a bit confused about the problem with the use of the APR atomic types. Is the problem that it is not supported on all platforms? If this is the case then isn't this a problem with the apr code? Even if a given OS doesn't specifically offer atomic types then (as menioned earlier) a simple mutex and int in a struct offers the same functionality. As far as I can see, all this wrapping should be part of the apr, shouldn't it? I think puting in #ifdef APR_USE_ATOMICS is a bit of band-aid solution; Whether or not atomics are OS supported the variables in question should really be only operated on atomically (in a multi-threaded environment) or else the code is not thread-safe. Also, I don't know if this has got anything to do with the compilation problems found but when I first put in the atomics I found that the implementation in the (fairly recent) version of the apr I had was broken (on NT) and caused compilation to fail. Getting the latest version fixed this problem. BTW Pier, sorry for not responding earlier - I managed to get the mod_webapp module compiling for Apache 2 after tweaking the 1.3 makefile to get a 2.0 makefile for NT. I used the apr directly from the Apache 2.0 distribution. At the moment I am using Apache 2.0 on an NT intranet server with the mod_webapp at it seems to behave identically to the 1.3 version. PS. If you want me to make any changes modifications (either changing the #ifdef or anything else) to the warp connector just let me know.... PPS. I noticed a comment about mod_webapp being deprecated. Is this the case? Simon. [EMAIL PROTECTED] wrote: > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
