Senility [was Re: [pygtk] timeout causes lockup?]
Doh! Just checked, and my Linux box at work has only Gtk+ 1.2.3 installed. It's the machine at home that has 1.2.6 installed. Of all the things I've lost in life I miss my mind the most. Mitch Chapman wrote: > > On Sun, 27 Feb 2000, you wrote: > > There were some threading bugs in some early versions of gtk+ > > (specifically with events_pending() and mainiteration()). You should > > really use gtk+ >= 1.2.4. I should have this check in the configure > > script. > ... > I'm probably missing something, but the foregoing doesn't seem to > explain the different behaviors between Linux and Solaris. Both > machines have Gtk+ 1.2.6 and pygtk 0.6.2. -- Mitch [EMAIL PROTECTED] To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] timeout causes lockup?
On Sun, 27 Feb 2000, you wrote: > There were some threading bugs in some early versions of gtk+ > (specifically with events_pending() and mainiteration()). You should > really use gtk+ >= 1.2.4. I should have this check in the configure > script. > > The other possible difference between the mandrake is if one was compiled > with threading and the other wasn't. I'm probably missing something, but the foregoing doesn't seem to explain the different behaviors between Linux and Solaris. Both machines have Gtk+ 1.2.6 and pygtk 0.6.2. Tomorrow I'll try to find out how the software was configured on Solaris. Sorry for the stupid question, but when you say "compiled with threading" are you referring to Gtk+, pygtk, or Python? Thanks for info. -- Mitch Chapman [EMAIL PROTECTED] To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] timeout causes lockup?
Yep, this was the problem: gtk before 1.2.5 did not call threads_(leave/enter) in gtk_main_iteration. thanks, - Scott > > There were some threading bugs in some early versions of gtk+ > (specifically with events_pending() and mainiteration()). You should > really use gtk+ >= 1.2.4. I should have this check in the configure > script. > > The other possible difference between the mandrake is if one was compiled > with threading and the other wasn't. > > James. > > -- > Email: [EMAIL PROTECTED] > WWW: http://www.daa.com.au/~james/ > > > On Sun, 27 Feb 2000, Scott Bender wrote: > > > > > Yeah, this is a strange one. I have one linux box (Mandrake 7) which does not >need the thread_enter/leave sutff, > > and another (RedHat 6.0) that does need it. They're both running the same pygtk >(0.6.3), but different versions of > > gtk, the Madrake box has 1.2.6, the RedHat box has 1.2.1. I'm guessing that this >is the reason. > > > > - Scott > > > > "Mitch Chapman" wrote: > > > > > > Here's an excerpt from a module of miscellaneous pygtk functions. > > > It shows three platform-dependent implementations of an update() > > > function. update() is used e.g. to update a progress bar > > > in the middle of a time-consuming operation -- it's analogous to > > > the Tkinter update() function. > > > > > > I haven't bothered looking at Gtk+ or pygtk sources in order to figure > > > out why you need threads_(enter|leave) on Solaris but not on Linux. > > > If somebody could explain the difference I'd be grateful. > > > > > > One last note: This code was tested w. pygtk 0.6.2, on all > > > three platforms. > > > > > > -- > > > Mitch > > > [EMAIL PROTECTED] > > > > > > > > Mitch Chapman wrote: > > > > > > > > On Sat, 26 Feb 2000, Scott Bender wrote: > > > > > Actually, the hang came after my timeout function completed. It was >calling mainiteration(FALSE) to > > > > > update a progress bar, which was causing the hang. Anyone know why? > > > > > > > > > > thanks, > > > > > - Scott > > > > > > > > I've seen this recently. The behavior varies depending on what version > > > > of Gtk+ you're running with, and on what operating system. > > > > > > > > The basic problem is that, on some platforms, even w. Gtk+ 1.2.6, > > > > you need to surround calls to gtk.events_pending() and > > > > gtk.mainiteration() with calls to gtk.threads_leave() and > > > > gtk.threads_enter(). On others (e.g. Solaris) you *shouldn't* do so. > > > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED] > > > > > > > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED] > > > > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED] > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] timeout causes lockup?
There were some threading bugs in some early versions of gtk+ (specifically with events_pending() and mainiteration()). You should really use gtk+ >= 1.2.4. I should have this check in the configure script. The other possible difference between the mandrake is if one was compiled with threading and the other wasn't. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sun, 27 Feb 2000, Scott Bender wrote: > > Yeah, this is a strange one. I have one linux box (Mandrake 7) which does not need >the thread_enter/leave sutff, > and another (RedHat 6.0) that does need it. They're both running the same pygtk >(0.6.3), but different versions of > gtk, the Madrake box has 1.2.6, the RedHat box has 1.2.1. I'm guessing that this is >the reason. > > - Scott > > "Mitch Chapman" wrote: > > > > Here's an excerpt from a module of miscellaneous pygtk functions. > > It shows three platform-dependent implementations of an update() > > function. update() is used e.g. to update a progress bar > > in the middle of a time-consuming operation -- it's analogous to > > the Tkinter update() function. > > > > I haven't bothered looking at Gtk+ or pygtk sources in order to figure > > out why you need threads_(enter|leave) on Solaris but not on Linux. > > If somebody could explain the difference I'd be grateful. > > > > One last note: This code was tested w. pygtk 0.6.2, on all > > three platforms. > > > > -- > > Mitch > > [EMAIL PROTECTED] > > > > > Mitch Chapman wrote: > > > > > > On Sat, 26 Feb 2000, Scott Bender wrote: > > > > Actually, the hang came after my timeout function completed. It was calling >mainiteration(FALSE) to > > > > update a progress bar, which was causing the hang. Anyone know why? > > > > > > > > thanks, > > > > - Scott > > > > > > I've seen this recently. The behavior varies depending on what version > > > of Gtk+ you're running with, and on what operating system. > > > > > > The basic problem is that, on some platforms, even w. Gtk+ 1.2.6, > > > you need to surround calls to gtk.events_pending() and > > > gtk.mainiteration() with calls to gtk.threads_leave() and > > > gtk.threads_enter(). On others (e.g. Solaris) you *shouldn't* do so. > > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED] > > > > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED] > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] timeout causes lockup?
Yeah, this is a strange one. I have one linux box (Mandrake 7) which does not need the thread_enter/leave sutff, and another (RedHat 6.0) that does need it. They're both running the same pygtk (0.6.3), but different versions of gtk, the Madrake box has 1.2.6, the RedHat box has 1.2.1. I'm guessing that this is the reason. - Scott "Mitch Chapman" wrote: > > Here's an excerpt from a module of miscellaneous pygtk functions. > It shows three platform-dependent implementations of an update() > function. update() is used e.g. to update a progress bar > in the middle of a time-consuming operation -- it's analogous to > the Tkinter update() function. > > I haven't bothered looking at Gtk+ or pygtk sources in order to figure > out why you need threads_(enter|leave) on Solaris but not on Linux. > If somebody could explain the difference I'd be grateful. > > One last note: This code was tested w. pygtk 0.6.2, on all > three platforms. > > -- > Mitch > [EMAIL PROTECTED] > > Mitch Chapman wrote: > > > > On Sat, 26 Feb 2000, Scott Bender wrote: > > > Actually, the hang came after my timeout function completed. It was calling >mainiteration(FALSE) to > > > update a progress bar, which was causing the hang. Anyone know why? > > > > > > thanks, > > > - Scott > > > > I've seen this recently. The behavior varies depending on what version > > of Gtk+ you're running with, and on what operating system. > > > > The basic problem is that, on some platforms, even w. Gtk+ 1.2.6, > > you need to surround calls to gtk.events_pending() and > > gtk.mainiteration() with calls to gtk.threads_leave() and > > gtk.threads_enter(). On others (e.g. Solaris) you *shouldn't* do so. > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED] > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] timeout causes lockup?
Here's an excerpt from a module of miscellaneous pygtk functions. It shows three platform-dependent implementations of an update() function. update() is used e.g. to update a progress bar in the middle of a time-consuming operation -- it's analogous to the Tkinter update() function. I haven't bothered looking at Gtk+ or pygtk sources in order to figure out why you need threads_(enter|leave) on Solaris but not on Linux. If somebody could explain the difference I'd be grateful. One last note: This code was tested w. pygtk 0.6.2, on all three platforms. -- Mitch [EMAIL PROTECTED] -snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip- # On IRIX we're running Gtk+ version 1.2.3. On Solaris and Linux we're # running 1.2.6. # On Linux, when performing a "manual" event loop to update the display, # you gotta be careful to release the Gtk+ mutex by calling # threads_(enter|leave). If you don't, the app will lock up when it # checks for pending events. # On IRIX, you can't call threads_enter, because we're using an old # version of pygtk which doesn't expose the threads_(enter|leave) # calls. # On Solaris, you can't call threads_(enter|leave) because if you do # the app will lock up when it checks for pending events. # # This all seems pretty bogus. But the following code works... if sys.platform[:5] == "linux": def update(): """Update the UI: flush pending rqsts and process pending events.""" gtk.gdk_flush() gtk.threads_leave() while gtk.events_pending(): gtk.mainiteration(0) gtk.threads_enter() elif sys.platform[:5] == "sunos": def update(): """Update the UI: flush pending rqsts and process pending events.""" gtk.gdk_flush() while gtk.events_pending(): gtk.mainiteration(0) else: # For IRIX w. Gtk+ 1.2.3: def update(): """Update the UI: flush pending rqsts and process pending events.""" # This solution was recommended on the pygtk mailing list, # by Bernhard Herzog <[EMAIL PROTECTED]>, the author of Sketch. # Speculation is that this is all due to a bug in recent versions # of Gtk+, e.g. 1.2.3 - 1.2.6. if hasattr(gtk, "gdk_flush"): gtk.gdk_flush() if hasattr(gtk, "threads_leave"): gtk.threads_leave() while gtk.events_pending(): gtk.mainiteration(0) if hasattr(gtk, "threads_enter"): gtk.threads_enter() -snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip- Mitch Chapman wrote: > > On Sat, 26 Feb 2000, Scott Bender wrote: > > Actually, the hang came after my timeout function completed. It was calling >mainiteration(FALSE) to > > update a progress bar, which was causing the hang. Anyone know why? > > > > thanks, > > - Scott > > I've seen this recently. The behavior varies depending on what version > of Gtk+ you're running with, and on what operating system. > > The basic problem is that, on some platforms, even w. Gtk+ 1.2.6, > you need to surround calls to gtk.events_pending() and > gtk.mainiteration() with calls to gtk.threads_leave() and > gtk.threads_enter(). On others (e.g. Solaris) you *shouldn't* do so. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] timeout causes lockup?
On Sat, 26 Feb 2000, Scott Bender wrote: > Actually, the hang came after my timeout function completed. It was calling >mainiteration(FALSE) to > update a progress bar, which was causing the hang. Anyone know why? > > thanks, > - Scott I've seen this recently. The behavior varies depending on what version of Gtk+ you're running with, and on what operating system. The basic problem is that, on some platforms, even w. Gtk+ 1.2.6, you need to surround calls to gtk.events_pending() and gtk.mainiteration() with calls to gtk.threads_leave() and gtk.threads_enter(). On others (e.g. Solaris) you *shouldn't* do so. I'll trudge in to the office in a bit and forward some relevant code, showing how to work around the problem on a handful of OS platforms. -- Mitch Chapman [EMAIL PROTECTED] P.S. This probably sounds kind of bogus. That's why I've not posted comments on it before -- I'm probably missing something obvious. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] timeout causes lockup?
Actually, the hang came after my timeout function completed. It was calling mainiteration(FALSE) to update a progress bar, which was causing the hang. Anyone know why? thanks, - Scott "Rob Hodges" wrote: > > > After a call to a timeout, which does gtk calls and network calls, > > my application locks up. Any ideas?? > > I've never looked at the code, but I assume timeouts are essentially > just inserted into the gtk mainloop. So if your timeout blocks, it > will stop the mainloop dead. Since you mention network calls, I'd > have to suspect that. > > -Rob > > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED] > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] timeout causes lockup?
> After a call to a timeout, which does gtk calls and network calls, > my application locks up. Any ideas?? I've never looked at the code, but I assume timeouts are essentially just inserted into the gtk mainloop. So if your timeout blocks, it will stop the mainloop dead. Since you mention network calls, I'd have to suspect that. -Rob To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] timeout causes lockup?
After a call to a timeout, which does gtk calls and network calls, my application locks up. Any ideas?? thanks, - Scott To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
