[pylucene-dev] strange beahavior of threads

Andi Vajda vajda at osafoundation.org
Thu Feb 10 12:01:39 PST 2005


> 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++).

Yes, that could be a problem indeed.

Andi..

>
> 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
>>>>>>> pylucene-dev at osafoundation.org
>>>>>>> http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> AV>
>>>>>
>>>>>
>>>>>
>>>>> Yura Smolsky,
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>> AV>
>>>
>>>
>>>
>>> Yura Smolsky,
>>>
>>>
>>>
>>>
>
>
>
> AV>
>
>
>
> Yura Smolsky,
>
>
>
>


More information about the pylucene-dev mailing list