Hi,
Threading does not work quite like that. You don't have to call
threads enter and threads leave before every funtion call, only when
you are making pygtk calls from another thread.
You would generally have:
if __name__ == '__main__':
gtk.gdk.threads_init()
gtk.gdk.threads_enter()
gtk.main()
gtk.gdk.threads_leave()
Then you would have a callback from another thread:
def other_thread_has_data():
gtk.gdk.threads_enter()
#do some gtk calls
gobject.add_idle(do_the_real_work_since_win32_sucks)
gtk.gdk.threads_leave()
Note that I added an idle call in my function callback, this is
because on win32, you can only make changes that affect the UI from
the main thread (ie where you called gtk.main() from).
-Chris
On Fri, 21 Jan 2005 10:23:22 +0100, Antoon Pardon
<[EMAIL PROTECTED]> wrote:
>
> I have been looking at the documentation of the gtk.gdk.threads_...
> functions. (*) at:
> http://www.pygtk.org/pygtk2reference/gdk-functions.html
>
> There I read under gtk.gdk.threads_init:
>
> | Theoretically any time a thread calls a PyGTK method or function it
> | should bracket the call with the gtk.gdk.threads_enter() and
> | gtk.gdk.threads_leave() functions. If your application only uses Python
> | threads then this is not necessary since only the main thread can safely
> | call PyGTK methods or functions.
>
> I thought this was mainly a Windows problem and that for example linux
> didn't have such problems.
>
> I was also wondering if it would be possible to change the signature
> of gtk.gdk.threads_init to something like:
>
> def gtk.gdk.threads_init(autolocking = TRUE).
>
> The idea would be that if autolocking is FALSE signal handlers wouldn't
> be called within a gdk_threads_enter() and gdk_threads_leave() function
> pair. My experience is that this embedding does little good but can be
> a serious pain in the bud, often enough being the cause of a deadlock.
>
> (*) With much thanks and appreciation to John Finlay
> who has done a marvelous job.
>
> --
> Antoon Pardon
> _______________________________________________
> pygtk mailing list [email protected]
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
>
--
Christopher Lambacher
[EMAIL PROTECTED]
_______________________________________________
pygtk mailing list [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/