В Сбт, 07/07/2007 в 15:56 +0200, Sebastian Pölsterl пишет: > Sebastian Pölsterl schrieb: > > It seems that some query threads don't seem to terminate. This behavior > > occures with modules that use to connect to the internet (yahoo) and the > > programs module causes this, too. > > Because the worker thread is still working on executing a previous query > > it's busy. If I type in a new query, another working thread will be > > blocked with this task. Eventually, all worker threads are blocked and > > new queries are queued and no new results will be displayed. > > > > Now I try to find out whether the ThreadPool or the module itsself is > > responsible for this. > > > I was pondering about the problem and I came to the conclusion that this > behavior is excepted. The thing is, if you wait long enough the > "blocking" threads terminate . It just takes some time. If a module > retrieves its results from the internet this can certainly happen. > > I thought about a solution and was hoping that killing the thread that's > blocking solves it. Unfortunatly, this is not supported by python. I > read some discussions about it and it seems that there isn't a clear > consensus whether this is good or bad. I'm not even sure that I > understand their concerns. Nevertheless, I found two hacks[1][2] that > try to solve this. Is it worth trying out one of these hacks or is > killing threads really evil? > > In those discussions they often promoted the solution to periodically > check if a variable or Event changed in the thread. Therefore, the > thread can "kill" itsself. In any case, this seems to be a clean > solution. The problem here is that it's just not possible with the > current module/query design. > > The last thing that came to my mind is to get rid of the ThreadPool and > start each query in its own thread at ones. > > To summarize: I got rid of the Xlib errors, but know I need our help to > find the best design to query the modules. The problem seems to be solved. The problem was in missing gobject.threads_init() and thus child threads were blocked since pygtk didn't release python global interpreter lock during gtk main loop iteration.
Attachment:
signature.asc
Description: =?koi8-r?Q?=FC=D4=C1?= =?koi8-r?Q?_=DE=C1=D3=D4=D8?= =?koi8-r?Q?_=D3=CF=CF=C2=DD=C5=CE=C9=D1?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=C1=CE=C1?= =?koi8-r?Q?_=C3=C9=C6=D2=CF=D7=CF=CA?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=D8=C0?=