Christian Reis <[EMAIL PROTECTED]> writes:
> On Sat, Oct 05, 2002 at 08:28:40AM -0400, Steffen Ries wrote:
> > class T(threading.Thread):
> > def run(self):
> > time.sleep(5)
> > gtk.threads_enter()
> > print "acquired GDK lock"
> > win = gtk.Window()
> > win.connect("destroy", lambda win: gtk.main_quit())
> > win.show()
> > gtk.threads_leave()
> > print "released GDK lock"
> >
> > gtk.threads_init()
> >
> > win = gtk.Window()
> > win.connect("destroy", lambda win: gtk.main_quit())
> > win.show()
> >
> > t = T()
> > t.start()
>
> t.run() vs t.start()?
t.start() creates a new thread which executes t.run() in parallel to the
main thread. IOW if you call t.run() directly, you're not leaving the
main thread, which defeats the purpose of the demonstration :-)
> Also, if I'm not mistaken locking is only important inside the mainloop;
> while you are out of it things should work as expected. You should
> protect GTK code that runs in handlers (though not signal handlers, as
> James points out).
The GTK+ documentation says that you have to wrap calls to gtk
functions with threads_enter/leave, if you are calling from a
different thread than the one running the main loop.
With gtk-1.2, I was using a different thread to update a list box based
on data received from the network. With gtk-2.0, I haven't tested this
function yet, but it looked like it worked. However, the new function
I was trying to implement crashed as soon as I allocated new gtk
objects (windows or changes in a TreeStore), just selecting a row in
the TreeView worked without problems.
/steffen
--
[EMAIL PROTECTED] <> Gravity is a myth -- the Earth sucks!
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
