sorry James, my email address changed and I forgot about the
restriction of this list. I hope this reply works without manual
intervention.
James Henstridge <[EMAIL PROTECTED]> writes:
[...]
> In answer to the question, the C interface does not grab the GTK lock when
> entering an IO callback, so the python one does not either. Maybe it
> should though -- I don't know. It probably doesnot call
> threads_enter/leave for you because the IO callback interface is
> implemented at the glib/gdk level.
I'm not sure what to do about it either, though it would be nice if it
could get fixed, because it's not obvious that one has to use those
calls. At some point the program will lock and it can't be debugged on
the level of the python language. In my case it suddenly happened
after upgrading some debian packages.
[...]
> If you think the current gtk behaviour is broken with respect to IO
> callbacks, I recommend you take it up with the GTK developers.
I'm not on that list right now but if I find some time in the next
days I will discuss it there.
[...]
> > Subject: threads_enter/leave required in a non-threading program
> > From: Andreas Degert <[EMAIL PROTECTED]>
> >
> > Hello,
> >
> > I'm using input_add() in a pygtk program to read from a socket. Both
> > gtk and python are compiled with threads (debian), but my program
> > doesn't use threads.
> >
> > When input is available on the socket, the supplied callback-function
> > is called. If this function tries to display a non-modal window, the
> > program locks up. The cure is to use threads_enter/leave in that
> > function.
> >
> > Is this expected behaviour?
thanks
Andreas
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
