[pygtk] Help: Problems with threads and pygtk

[David Hirschfield]

Yeah, I have that around my call to gtk.main(), although as far as I =

know you shouldn't need it unless your thread code touches gtk widgets =

or calls gtk functions.

The code in my thread does none of that, it only accesses database =

connections, sockets and some special xml-rpc stuff. There is no =

crossover between the thread and the UI except via the synchronized =

queue which handles requests, that's all.

I can't figure out what part of the request processing is causing the =

freeze, it just freezes solid in the middle of some random assignment or =

list.append(), for no apparent reason. There must be some kind of =

contention, or a messed-up interpreter stack.

-Dave

N. French wrote:
> Did you surround any accesses to GTK objects with the below calls?
>
> gtk.threads_enter() # can't touch a GTK object w/o a thread lock
> ...
> gtk.threads_leave()
>
> Without this bad stuff will happen.  I admit I don't fully understand
> why this is needed but I found it either on the FAQ or someone
> suggested it here.
>
> --- David Hirschfield <davidh at ilm.com> wrote:
>
>   =

>> I've run into a serious problem using threads with pygtk, and I was =

>> hoping someone could give me suggestions.
>>
>> My program is a pygtk interface with a "processor" thread that pulls =

>> from a safely synchronized queue of "requests" and processes each
>> one.
>> Seems simple, and it should have been...but it freezes solid when I
>> run =

>> it. Not a traceback of any kind, the interface and the python =

>> interpreter freeze.
>>
>> I've checked all the things that should be obvious problems:
>>
>> I'm calling:
>> gobject.threads_init()
>> gtk.gdk.threads_init()
>> before gtk.main() is called
>>
>> There is no race condition or blocking call causing everything to get
>> stuck.
>> The thread's only interaction with the rest of the program is via the
>>  =

>> Queue.Queue object that keeps the requests to be processed.
>>
>> I've stepped through with pdb and it freezes in a completely
>> innocuous =

>> place in the code (during a loop where I append to a list).
>> The freeze occurs in slightly different places depending on what kind
>> of =

>> debugging code I put in, changes to the order of things, etc...so it =

>> feels like it's some kind of corruption in the interpreter stack.
>>
>> Running the processor thread in a dummy app without the pygtk part
>> never =

>> freezes up.
>> Running the pygtk app with a non-threaded processor, which just =

>> sequentially runs the requests and waits till they complete, never =

>> freezes up.
>>
>> I'm at my wit's end here...I know threads are just asking for
>> trouble, =

>> and usually I avoid them, but circumstances here basically require =

>> threading (all the request time is spent waiting on different kinds
>> of =

>> IO). The setup was so simple, I figured I couldn't possibly run into =

>> trouble...yet here I am.
>>
>> So, anyone have any idea what could cause the entire python
>> interpreter =

>> to freeze solid? Are there known issues with pygtk and python threads
>>
>> that I should be aware of? Is there some way to verify that the =

>> interpreter stack is not getting screwed up somehow?
>>
>> Any help at this point would really be useful,
>> -Dave
>>
>> -- =

>> Presenting:
>> mediocre nebula.
>>
>> _______________________________________________
>> pygtk mailing list   pygtk at daa.com.au
>> http://www.daa.com.au/mailman/listinfo/pygtk
>> Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
>>
>>     =

>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around =

> http://mail.yahoo.com =

>
>   =


-- =

Presenting:
mediocre nebula.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.daa.com.au/pipermail/pygtk/attachments/20061005/6649212a/at=
tachment.htm