Hello, Andi. It is not me! :) It is sources of omniORBpy. They use complicated logic about management of threads. I suspect one very bad thing: they can start new threads from C++ sources (some part of this software has been written on C++).
AV> I don't understand why this class is so complicated and what you're doing with AV> those _thr_ variables. All you need to do from PyLucene's standpoint is extend AV> PyLucene.PythonThread, ensure its __init__ is called, instantiate the thread, AV> and then start it with its start() method. AV> Andi.. AV> On Thu, 10 Feb 2005, Yura Smolsky wrote: >> Hello, Andi. >> >> yes, it has. >> i am not confident about _thr_act, _thr_acq, _thr_rel variables. >> maybe they could affect. >> >> _thr_init = PythonThread.__init__ >> _thr_id = threading._get_ident >> _thr_act = threading._active >> _thr_acq = threading._active_limbo_lock.acquire >> _thr_rel = threading._active_limbo_lock.release >> >> class WorkerThread(PythonThread): >> >> hooks = [] >> >> def __init__(self): >> _thr_init(self, name="omniORB") >> self._Thread__started = 1 >> self.id = _thr_id() >> _thr_acq() >> if _thr_act.has_key(self.id): >> self.add = 0 >> else: >> self.add = 1 >> _thr_act[self.id] = self >> _thr_rel() >> if self.add: >> for hook in self.hooks: >> hook(WTHREAD_CREATED, self) >> >> def delete(self): >> if self.add: >> for hook in self.hooks: >> hook(WTHREAD_DELETED, self) >> _thr_acq() >> del _thr_act[self.id] >> _thr_rel() >> >> def _set_daemon(self): return 1 >> def join(self): assert 0, "cannot join an omniORB WorkerThread" >> >> >> AV> Does the WorkerThread class that extends PyLucene.PythonThread have an >> AV> __init__() method ? If so, does it call super(WorkerThread, >> AV> self).__init__(*args, **kwds) so that >> PyLucene.PythonThread's __init__ gets a >> AV> chance to run ? >> >> AV> Andi.. >> >> AV> On Thu, 10 Feb 2005, Yura Smolsky wrote: >> >>>> Hello, Andi. >>>> >>>> I have checked through threading.currentThread() that code executed >>>> under thread inherited from PythonThread. What could be wrong in this >>>> case? >>>> >>>> AV> Yes, 'collecting from unknown thread' means that libgcj is running a >>>> thread >>>> AV> that was not initialized by it. >>>> >>>> AV> Andi.. >>>> >>>> AV> On Sat, 1 Jan 2005, Yura Smolsky wrote: >>>> >>>>>> Hello, pylucene-dev. >>>>>> >>>>>> As I said early I try to run IndexSearcher under omniORBpy (CORBA) >>>>>> server, which creates new thread for any call of server's method by >>>>>> remote client. >>>>>> I have replaced in the source of omniORBpy >>>>>> WorkerThread(threading.Thread) to >>>>>> WorkerThread(PyLucene.PythonThread). >>>>>> >>>>>> But when I try to call some methods of server remotely then I got java >>>>>> message from Server which contains IndexSearcher: >>>>>> >>>>>> Collecting from unknown thread. >>>>>> >>>>>> It seems like message is about garbage collection. >>>>>> Does it mean that server start non PythonThread thread?.. What issue >>>>>> does this message point to? >>>>>> >>>>>> >>>>>> Yura Smolsky >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> pylucene-dev mailing list >>>>>> [email protected] >>>>>> http://lists.osafoundation.org/mailman/listinfo/pylucene-dev >>>>>> >>>> >>>> >>>> >>>> AV> >>>> >>>> >>>> >>>> Yura Smolsky, >>>> >>>> >>>> >>>> >> >> >> >> AV> >> >> >> >> Yura Smolsky, >> >> >> >> AV> Yura Smolsky, _______________________________________________ pylucene-dev mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
