On Wed, 13 Sep 2006, Phillip J. Eby wrote:
At 10:07 AM 9/13/2006 -0700, Andi Vajda wrote:
If PyLucene never released the GIL then the system would appear to hang
temporarily when, for example, optimizing indexes which can take several
seconds (or more).
Also, since one can write python extensions to PyLucene, it can call back
into python. Because of this and because acquiring the GIL is not
re-entrant - Phillip, correct me if I'm wrong - the GIL has to be acquired
or released anytime the Python / C++ boundary is crossed.
Not really. You *can* release the GIL in order to allow Python code to run
alongside you, but there is no requirement that you do so. Normally,
releasing the GIL is something that happens only when waiting for I/O or
doing calculations that may run for an extended period. So, it certainly
makes sense to release it in the PyLucene case, but it's not a requirement
that all C or C++ code must follow.
Well, it can get a little messy pretty quickly. If one doesn't deal with the
GIL when calling back and forth from Python to C++/Java, then when a Java
thread that is not controlled from Python with the GIL calls into python,
things can get ugly. With Java, the finalizer thread comes to mind. But, in
the case of Lucene, it is also possible for it to create threads on its own,
without going through Python first, and at the low level, there is no solid
way (no, thread naming doesn't count) to distinguish between a
thread-controlled-by-python-with-the-GIL and others. But we're getting off
topic, here, apologies...
But regarding the locale issue, the hard part is that the problem doesn't
appear to be reproducible in a reliable way, so confirming *anything* about
the problem is virtually impossible.
Hence, my earlier suggestion (on the parallel bugzilla thread), of switching
to using the PyICU number parsing routines instead.
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
