Re^2: Gtk2 app -- what's better, threads, or multiple timeouts?

in reply to Re: Gtk2 app -- what's better, threads, or multiple timeouts?
in thread Gtk2 app -- what's better, threads, or multiple timeouts?

If you are experiencing lag, then either 1) run the main loop occasionally during cpu-intensive functions

Okay I'm not sure I understand this. I was under the impression that the main loop was always running. Does this mean that when I run a timeout, the main loop "waits" for whatever the timeout does to finish before it continues on? Observing my program it does seem like that is the case.

Each run of the timeout in my program polls a certain website for changes, parses the new data (if any) and if there's something new it displays the data in the gui. So each run of the timeout has to wait for the webpage to be fetched which is where the slowdown is coming from.

If I'm understanding how the main loop works, I think I'd like to have the main loop not wait for anything the program does in the background, but again I'm not sure if that's the right way to solve the problem. (Update: I should clarify that what I mean by "anything the program does in the background" is anything like the polling of the website that is not triggered by any gui events, it just does that all the time. In other words I want these background functions to be a seperate operation that doesn't effect the gui (unless there's something new to be displayed). Hopefully I'm making sense here ;-)

Comment on Re^2: Gtk2 app -- what's better, threads, or multiple timeouts?

Replies are listed 'Best First'.
Re^3: Gtk2 app -- what's better, threads, or multiple timeouts? by GrandFather (Saint) on Feb 06, 2009 at 05:28 UTC
The golden rule of event driven code is "never wait". Often that means that you need to initiate a process (start the fetch) then return and handle the reply some time in the future. One thing that implies is that you can only make non-blocking calls in the event processing. Perl's payment curve coincides with its learning curve.	[reply]
Re^3: Gtk2 app -- what's better, threads, or multiple timeouts? by traveler (Parson) on Feb 06, 2009 at 16:40 UTC
If you are experiencing lag, then either 1) run the main loop occasionally during cpu-intensive functions Okay I'm not sure I understand this. I was under the impression that the main loop was always running. Does this mean that when I run a timeout, the main loop "waits" for whatever the timeout does to finish before it continues on? Observing my program it does seem like that is the case. The main loop waits for events. When it gets one it processes it. If the event it is processing is a timer event tied to a sub of yours, it runs the sub. (Don't) try this `while (1) { ... }` [download] It will hang the GUI. So in an event-driven environment such as Gtk2 you allow events to trigger subs. Never have your code sit around waiting for something to happen, that is the main loop's job. When something happens it will trigger an event (if you ask it to) and run your sub. The only time you should ask Gtk2 to process pending events if if you have a compute intensive block of code. For instance, if you are sorting a few zillion items, every once in a while (pun intended) try `Gtk2->main_iteration while Gtk2->events_pending;` [download] This runs the main iteration code (which is what loops in the main loop while there are any events pending. Of course, you need to make sure that this does not mangle the data you are processing.	[reply] [d/l] [select]

In Section Seekers of Perl Wisdom