> Looking at the C source of the conversion function Python uses, it > appears as though *in theory* a race condition could occur, where the > conversion function gets the current locale, replaces the decimal point > in the input string, and then somebody in another thread *changes* the > locale, such that the converted string doesn't match. In other words, > float() converts it to a French float string, and then it sees a > non-French locale when converting it. Such an error would be incredibly > difficult to reproduce, and it would require that the other thread be > running pure C or C++ code without holding the GIL. I don't know if > this is even remotely possible as a cause here, though. We would need > to have something like that running in a thread somewhere, and I don't > know if we do. And it would have to be switching locale stuff around.
Thanks, PJE. This seems to describe the symptoms Philippe saw (once). Off hand, the wx i18n code or PyICU seem like plausible vectors for C++ code that could be tweaking locale in a different thread, but I don't know enough about what they do with locale and the GIL to know how likely either are. Actually, it seems unlikely that wx is the source of a race condition, because the exception is in the midst of running UI code, which is presumably the only thread wx code runs in. Andi, do you know if PyICU ever releases the GIL as it runs a routine? Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
