Re: fork() and progress bar...

[Jeff Shipman - SysProg <jeff nmt edu>]

} GTK never gets to control again, and so nothing is delivered to the X
} server until you're all done, at which point, you'll get a brief flash
} of updating, and thats it.

But the functions that I'm calling to update the
progress bar have

while(gtk_events_pending()) gtk_main_iteration();

Isn't this sending control back to GTK? I see several
flickers (one per time through the loop), so it seems
like it is getting control, just that it's too fast.

} i would install a GTK timeout handler with a timeout of about
} 100msecs. cancel the timeout handler by returning FALSE from it once
} the SQL thread if finished (return TRUE to have it be called
} again). Use a static variable in the handler callback to decide which
} direction you're moving in.

So I would do something like this (never done handlers before
so this is kinda pseudo-codeish):

my_100msec_handler()
{
   ...
   the for loops
   ...
   if(*running) return TRUE;
   return FALSE;
}

Kinda like that? Thanks for your help.

Jeff Shipman           E-Mail: jeff nmt edu
Systems Programmer     Phone: (505) 835-5748
NMIMT Computer Center  http://www.nmt.edu/~jeff

On Fri, 7 Sep 2001, Paul Davis wrote:

} >Ok, I've set up an extra thread with the progressbar updating
} >in the main thread and the mysql query happening in the
} >other thread. It works great and mysql loads and there's no
} >crashes. However, when the 'Fetching...' part happens, it says
} >'Fetching...', but the progressbar just flickers very fast,
} >like it's updating too quickly. I tried upping the usleep()'s,
} >but that never worked. Under the fork() mechanism, the for
} >loops I have there did the updating at the perfect rate. If
} >someone could help me out with figuring out those speed issues,
} >I'd really appreciate it. I've attached a recent copy of my
} >code below.
}
} you're updating ever 5 *MICRO* seconds! first of all, the kernel will
} quantize that to a minimum of 1/HZ seconds (where HZ is almost
} certainly 100 on your system). second, since the screen refresh rate
} is only about 70Hz, any value faster than this is wasting CPU time.
} finally, none of the screen updates will happen until you return
} control to GTK, which you never do, since your loop looks like:
}
} 	while (running) {
} 		modify progress bar
} 		sleep
}         }
}
}
} --p
}
}
}
}
}
}
}