[pygtk] PyGTK Thread problem

[Funky Fred]

>Maybe all you need is the setDaemon method on your threads.
>
>--
>Antoon Pardon

Naw, I tried that a while ago, and it didn't do anything...
Well, it did what it said, that is, the worker threads kept running in the
background, and calling update callbacks to nothing. I guess everything
would exit cleanly, just a little late...

I could set the die flag and exit, and they would probably stop sooner.
A real problem is that some of the threads are using popen4 to invoke
command-line tools (part of this is integrating a mess of disparate command 
line tools into
a nice, easy to use interface). These tools tend to be computationally 
expensive at times.
Ever run several instances IDA -B at once? (interactive disassembler).
And I would like to regex the asm output after that, to give you an idea.
And possibly several other tools running in parallel. Oy.

What I was kind of bitching about is I want everything to just go away when 
I tell it too.
Impatient ;)

But while I'm making a wish list... what I would _really_ like is to have 
multiple
threads running on multiple cores ;)
(I've been told python doesn't do this, maybe it already does, and I just 
don't know).
Heck, clustered python .. we can always dream..

Actually what I have been thinking about is the affect that py2exe has on 
threaded programs.
What does that do to the GIL? Is the thread switching now hard-coded? I 
wouldn't think so.
Haven't looked into it, I may try it out tomorrow, and be bugging you guys 
about that..

btw, I _do_ appreciate all the help, but my current hit list is

- an issue with GTK text views and + 10 MB files taking a couple seconds to 
load (Impatient again).
- some things that I _know_ are caused by my bad code somewhere (stuff 
repeatedly being initialized when it should only be done once or twice)
- py2exe ? pyrex? Why did I once have three instance of IDA running at the 
same time, suddenly just go idle, but never complete? (possibly it was 
waiting for human interaction..)

Nearly all the time, just telling all the threads to die, sleeping 2-3 
seconds, and then calling sys.exit works for me now.

Thanks,
-Stu

>From: Antoon Pardon <Antoon.Pardon at rece.vub.ac.be>
>To: pygtk at daa.com.au
>Subject: Re: [pygtk] PyGTK Thread problem
>Date: Mon, 30 Apr 2007 20:42:11 +0200
>
>On Sat, Apr 28, 2007 at 11:39:01PM +0000, Funky Fred wrote:
> >
> > >Maybe the idea is usefull for you.
> >
> > Hmm. It's definitely something I plan to keep in my head.  I'm a little
> > wary of mucking with the interpreter at that level (that warning about
> > "naive use" of PyThreadState_SetAsyncExc in the documentation definitely
> > would apply to my knowledge level of python internals at this point).
> > However, I may end up having to...
> >
> > For now, though, trying to get the threads to exit cleanly is an 
>aesthetic
> > thing (a flag and sys.exit() does the job, albeit with the occasional
> > exception when a thread doesn't check it's flag in time). Heck just 
>going
> > into process explorer and killing the thing is acceptable at this stage.
> > But this may change, and I'll be searching for this e-mail again....
>
>Maybe all you need is the setDaemon method on your threads.
>
>--
>Antoon Pardon
>_______________________________________________
>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/

_________________________________________________________________
Need a break? Find your escape route with Live Search Maps. 
http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01