From: Jonathan Blandford (jrb@redhat.com)
Date: Mon Aug 05 2002 - 15:19:11 EDT
Dom Lachowicz <doml@appligent.com> writes:
> Martin,
>
> > Threads actually interupt the flow of code. Say we have a blinking
> > cursor, that fires while we're doing a recalculation of the document
> > length in the piece table, or we're handling a scroll event and in the
> > middle of blitting graphics to the screen, or we're doing a redraw
> > update. We can't redraw the cursor during any of these processes because
> > either document position is changing or the screen is changing
> > underneath you and used to be black might white or vice-versa.
> > Everything that is remotely useful has to be allowed to be finished. The
> > only time it's safe to actually run a thread based timer is if we're
> > idling in the main-loop. And we already have a mechanism to do that.
>
> Just FYI, no such guarantee is made. Timers and idles are totally
> capable of interrupting the normal flow of your code, or are at least
> not guaranteed *not* to do so. AFAIK,the idle loop is just guaranteed
> to run while GTK is not processing other drawing commands. So when
> you're (eg) calculating the length of a run, you're not drawing
> anything using GTK+. No such restrictions are placed on the timer,
> though it may be implemented in terms of the idle loop at this point
> in time. Documentation to the contrary would be appreciated.
http://developer.gnome.org/doc/API/2.0/glib/glib-the-main-event-loop.html#g-timeout-add
The timer is implemented using the main loop. It won't interrupt your
code at all (like a Unix signal). It should be safe.
Thanks,
-Jonathan
This archive was generated by hypermail 2.1.4 : Thu Aug 08 2002 - 09:37:27 EDT