On Wed, 08 Jun 2005 09:01:26 -0400, Antoon Pardon
<[EMAIL PROTECTED]> wrote:
On Wed, Jun 08, 2005 at 02:22:31PM +0200, Vincent Bernat wrote:
OoO Peu avant le début de l'après-midi du mercredi 08 juin 2005, vers
13:53, Antoon Pardon <[EMAIL PROTECTED]> disait:
> | John K. Luebs reminds you: *don't forget gtk.threads_enter() and
> | gtk.threads_leave()* around mainloop when accessing gtk code if you
want
> | your application to actually work threaded:
> |
> | gtk.gdk.threads_enter()
> | gtk.main()
> | gtk.gdk.threads_leave()
> I think this is wrong although it doesn't seem to hurt.
>> From the reference pages I understand that gtk.gdk.threads_init
> initializes a lock and that gtk.gdk.threads_enter() acquires
> this lock while gtk.gdk.threads_leave() releases it. In any case
> it is all about marking critical sections.
> Now marking the gtk.main() as such a critical section would
> mean that all other threads wanting to enter a critical section
> with gtk.gdk calls would be stopped from doing so until gtk.main
> had quit. That seems less than usefull.
As a side note, I have got my application working using this
trick. This seems odd to me too but without this, I was not able to
run the application on win32, even when all the gui operations are
made on the main thread (as suggested). On Linux, no problem.
Well in that case I think this would be more appropiate in entry 21.3.
The behaviour described in the grand-parent post also affected my program
in Linux, which is why it's probably more suited to being 20.6 instead of
21.3.
Jody Steele
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
pygtk mailing list [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
