On Fri, 9 Dec 2005, tsuraan wrote:
I read in the readme that you had to write the PythonThreads class to
get around the differences between java (gcj) threading and python
threading. My application exposes the functionality of lucene through
the threaded soap server of SOAPpy, which (I assume :) doesn't use the
PythonThreads class. Would I then, in the thread started by the soap
server, just start another PythonThreads thread to do the actual
lucene work? Can a PythonThread started from a normal thread work
correctly with regards to not breaking lucene? That's the only big
question I have right now. PyLucene looks really nice.
For any threaded libgcj usage, the thread *has* to be started by
java.lang.Thread. This is a limitation of libgcj's garbage collector. The
author of the GC module, Hans Boehm, is aware of that problem and is working
on a fix. Earlier today, he posted this to the [EMAIL PROTECTED] mailing list:
http://gcc.gnu.org/ml/java/2005-12/msg00126.html
I don't expect a fix to show up in gcj in the near future - this bug is very
old - so, for the foreseeable future, threaded libgcj usage needs to work
around this. This workaround has nothing to do with python, the problem is the
same with raw C or C++.
The PyLucene.PythonThread class is a subclass of python's threading.Thread
class that delegates the actual starting of the OS thread to java.lang.Thread.
To python, this thread looks like one of its own.
As for SOAP or Twisted or any other such python threaded networking server
software, there usually is a way to override the thread creation. For example,
in twisted, we - Chandler at OSAF - created a custom thread pool that makes
PyLucene.PythonThread instances instead of threading.Thread ones.
Andi..
_______________________________________________
pylucene-dev mailing list
[email protected]
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
