Re: Status report 'Refactoring Deskbar-Applet' 02.07.2007

[Sebastian Pölsterl <marduk k-d-w org>]

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.

[1]:
http://www.velocityreviews.com/forums/t330554-kill-a-thread-in-python.html
[2]: http://www.dlevel.com/blogs/alex/20

-- 
Greetings,
Sebastian Pölsterl