Message2354

Logged In: YES 
user_id=61408

first, no problem, and thanks. It is not that didn't believe
there was a problem, but I like to know what exactly I'm fixing.
So far, I didn't notice it but yes PyJavaClass is abusing in
some spots
the "Double-Checked Locking" idiom which is not safe either
under the old or new Java memory model. I think they are
there from long time in the history of the project.

1) I fear that PyFile.softspace problem is just the tip of
an iceberg,
I think our file layer is in general not thread-safe, but
yes at least print statements should be, I think the
synchronization should be done some level higher for that.

2) the analysis is dynamic right? and there are also some
false positives e.g
    private static int nameindex=0;
    public static synchronized String getName() {
        String name = "org.python.pycode._pyx"+nameindex;
        nameindex += 1;
        return name;
    }

3) yes there are data races for initialized,
constructorsInitialized ,__bases__,proxyClass and __init__
in PyJavaClass and also trashing of missingAttributes and
keywords.
 that  were not spotted.

4) why do you exactly decided to go with a class-level lock,
is there a particular reason or just defensive programming?

I understand that in the scheme using both a class lock and
an instance lock, there is a risk to try to acquire them in
different orders on different threads with the danger of
deadlocking, OTOH as far as I see, the code working under
the old class lock
doesn't invoke synchronized code on single instances.

All fields should be set by each single PyJavaClass on its own,
except for proxyClass which should be initalized holding a
class-level lock because the Class->PyJavaClass table should
be manipulated at the same time.

5) is this for 2.1 code or the CVS?