I'm cross-posting since this started on the user list.

In Tomcat 3.3, JspServlet is largely deprecated (even if not yet
@deprecated).  It is only still included in case some 3.2.x user really
needs it for something.  It is much more likely to be removed in a future
release than fixed.

That being said, we always welcome patches :).

----- Original Message -----
From: "Bo Xu" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, December 06, 2001 11:50 AM
Subject: Re: DO NOT REPLY [Bug 4138] - HttpProcessor threads have
inconsistent ClassLoader state


> Dear TOMCAT developers, :-)
>
>
> I forward the following email to you :-)
>
> Bo
> Dec.06, 2001
>
> *****************************************************************
>
> If you really want the developers to take a look at this, you should
> probably post it to the tomcat-dev list. It's iffy whether or not they
will
> see it here.
>
> Thanks,
> --jeff
>
> ----- Original Message -----
> From: "java programmer" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, December 05, 2001 10:44 PM
> Subject: Double check idiom broken - Tomcat uses it ?
>
>
> > Hi all:
> >
> > We all know that the lazy-double-check idiom doesn't
> > apply to Java because of the Java Memory Model (JMM).
> >
> > That is to say, look at code such as:
> >
> > Example a)
> > // Set by any other thread other than #1
> > volatile boolean stop = false;
> >
> > // Thread #1 runs this as long as
> > // stop is false. Only T1 will call this
> > // method, so not synchronized. hence
> > // broken due to staleness of 'stop'.
> > // synch for _visbility_ ALSO.
> > void foo() {
> >  while (!stop ) {  //... }
> > }
> >
> >
> > Example b): The lazy double check idiom
> > public static Foo haha = null;
> > public static getFoo() {
> > if (foo == null ) {
> >   sychronized (Foo.class) {
> >      if (foo == null )
> >             foo = new Foo();
> >   }
> > }
> > return foo;
> > }
> >
> > Both examples are *guaranteed* to be incorrect.
> > Note, this is the case, *even* though I am using
> > 'volatile' for the stop variable. For more on the
> > JMM, consult Item #48 in Effective Java (Josh Bloch),
> > look at Bill Pughs' page at:
> > http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> > or check out Doug Lea's stuff.
> > Well, here is the thing:
> >
> > Quite idly, and randomly, I was looking at:
> >
> > org.apache.jasper.servlet.JspServlet
> >
> > and I found:
> >
> > <snip>
> > outDated = compiler.isOutDated();
> >    if(!jsw.isInstantiated() || outDated ) {
> >       synchronized(jsw){
> >         outDated = compiler.compile();
> >         if(!jsw.isInstantiated() || outDated) {
> >         if( null ==ctxt.getServletClassName() ) {
> > <snip>
> >
> > This is a complex use of double check type
> > code and is really hard to analyse because references
> > themselves and what they point to can have
> > different levels of staleness (according to the JMM).
> > So it's a turbo double idiom type usage, possibly
> > incorrect.
> >
> > I just wanted to bring this to the attention of the
> > development team and make sure that *someone* has
> > really analysed this according to the JMM. (and
> > any other code, similar to this).
> >
> > Best regards,
> >
> > [EMAIL PROTECTED]
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


*----*

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to