Skip Montanaro wrote: > Mike> To use the locking mechanisms, you'd first intialize the threads > Mike> with code like: > > Mike> gtk.threads_init () > Mike> gtk.threads_enter () > Mike> gtk.mainloop () > Mike> gtk.threads_leave () > > Mike> #... Now comes other code in another thread > Mike> gtk.threads_enter () > Mike> # Modify a widget or something > Mike> gtk.threads_leave () > >It seems then that gtk.threads_enter/leave is functionally like the >acquire/release methods of a threading.RLock instance, it's just that the >gtk C code knows how to manipulate that single lock. I think I'm >synchronized now. > The PyGTK threading support is really comprised of the following:
1) wrappers for functions used to acquire/release the GDK lock 2) add code to release/acquire python interpreter lock where appropriate (this includes some code to try and fake a recursive interpreter lock -- would be nice if the python interpreter lock was recursive :). This allows threads to run during the gtk.main() call. 3) provide a function that can be used to turn on the threading support (the gtk.threads_init() call). If you only want to write a single threaded app, having gdk thread support turned on requires the programmer to have to worry about the gdk lock (such as remembering to acquire the lock in idle/timeout functions where appropriate). The example program attached to the first message in this thread is an example of its use (although there are either some bugs in the program, the code in pygtk, or gtk itself that cause multiple threads to write to the X socket at once occasionally). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
