Author jeff.allen
Recipients Ivan, jeff.allen, zyasoft
Date 2017-08-01.21:36:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I think you've got it Jim.

To elaborate on my understanding ... two threads Alice & Bob start. Alice calls REGEX.match and gets a MatchObject result. Alice finds no PyType for a MatchObject, and adds one (maybe here: Meanwhile Bob starts up, receives a MatchObject and finds the PyType Alice created. But Alice is still building it, and Bob uses it before Alice can finish filling it in.

An observation supporting this theory is that in a few cases the error is a Java NPE thrown from here: . 

I find, on Windows, that I get the error much sooner if I print out the arguments during parse(), in the first block normally. Not sure why. However, in that condition of frequent early failure, if I add early in the main program:

sample ="foo23E")

it will run forever (ok, 20 minutes) without raising. Comment it out and it fails immediately. Of course, that line will fully construct (and keep alive) an instance of PyType corresponding to MatcherObject, and do so before the threads start.

There's an attempt here:
to do without the synchronisation, arguing that multiple construction is harmless, because the first thread to set a PyType in the map will win, and the duplicates can be discarded. This argument only works if the object is fully constructed by the time it is entered in the map.

But even then, might this be overlooking the question of cache coherence? The map entry could be absent in one processor's view of memory and not in the other's.
Date User Action Args
2017-08-01 21:36:10jeff.allensetmessageid: <>
2017-08-01 21:36:10jeff.allensetrecipients: + jeff.allen, zyasoft, Ivan
2017-08-01 21:36:10jeff.allenlinkissue2609 messages
2017-08-01 21:36:09jeff.allencreate