[EMAIL PROTECTED] wrote: > 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?
No it is not yet 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.] Yep, there is an apr_atomic.c file that could be used as generic atomic code. > > 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. The status of atomic is not 100% clear in APR. Someone from RedHat tells it will not work in user space (at least on Linux)(see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=63643). For mod_webapp probably the best might be to use mutex instead of atomic. > > 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.... I committed your changes. For the moment I think we should wait to see what happends in APR... > > PPS. I noticed a comment about mod_webapp being deprecated. Is this the > case? > No. It is just commented out in the server.xml that is delivered with the TC binaries. > > 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]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
