Author jeff.allen
Recipients Ivan, jeff.allen, zyasoft
Date 2017-07-31.08:27:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I agree that it is likely to be a general problem with initialisation rather than specific to the thread safety of re. Investigation has led me into code that is generic to the support of types.

This is because, in circumstances (on my Linux box) where the error occurs, I've been able to catch m.__class__.__dict__.items() empty.

The observation that if its going to happen, it happens early, is misleading. I think this may be something to do with it being more likely when the machine is busy (or not busy, who can say). On my Windows machine, which is the only place debugging is a satisfatory experience, the same code will produce the error, but it takes around ten thousand calls. I can't reconcile this with the idea that it is synchronisation of the initialisation of the type that's at fault.

However, not understanding and fully, and given they're in the time frame b3-release, reverting them seems worth a try to me. I could probably try that this evening (UK time). It is clear from comments that we had our doubts about them. With hindsight, given this is a critical bit of the Jython core, and threading is so difficult, either proof or a massively beefy test of correctness was in order.

So far my own investigation has only led me into into MethodCache.lookup_where(). Speaking of hindsight, what I really need for this is a way to catch the miss, then single-step *backwards* into methods that just returned :)
Date User Action Args
2017-07-31 08:27:04jeff.allensetmessageid: <>
2017-07-31 08:27:04jeff.allensetrecipients: + jeff.allen, zyasoft, Ivan
2017-07-31 08:27:04jeff.allenlinkissue2609 messages
2017-07-31 08:27:02jeff.allencreate