tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfrederic.cl...@fujitsu-siemens.com>
Subject Re: mod_webapp.so socketpool changes..
Date Tue, 30 Apr 2002 14:14:42 GMT
simonkeary@eircom.net 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.
 >
 > jfrederic.clere@fujitsu-siemens.com wrote:
 >
 >
 >> Pier Fumagalli wrote:
 >>
 >>> "Cavan Morris" <cavan.morris@worldnet.att.net> 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"
 >>>> <pier@betaversion.org> To: "Tomcat Developers List"
 >>>> <tomcat-dev@jakarta.apache.org> Sent: Saturday, April 27, 2002 8:58
AM
 >>>> Subject: Re: mod_webapp.so socketpool changes..
 >>>>
 >>>>
 >>>>
 >>>>
 >>>>> "Cavan Morris" <cavan.morris@worldnet.att.net> 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:tomcat-dev-unsubscribe@jakarta.apache.org> For additional
 >>>>> commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
 >>>>>
 >>>>>
 >>>> -- To unsubscribe, e-mail:
 >>>> <mailto:tomcat-dev-unsubscribe@jakarta.apache.org> For additional
 >>>> commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
 >>>
 >>>
 >>> -- 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:tomcat-dev-unsubscribe@jakarta.apache.org> For additional
 >>> commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
 >>>
 >>>
 >>>
 >>
 >>
 >>
 >> -- To unsubscribe, e-mail:
 >> <mailto:tomcat-dev-unsubscribe@jakarta.apache.org> For additional
 >> commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
 >>
 >>
 >
 >
 > -- To unsubscribe, e-mail:
 > <mailto:tomcat-dev-unsubscribe@jakarta.apache.org> For additional commands,
 > e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
 >
 >
 >




--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message