From: Jonathan Blandford (firstname.lastname@example.org)
Date: Mon Aug 05 2002 - 15:19:11 EDT
Dom Lachowicz <email@example.com> writes:
> > 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.
The timer is implemented using the main loop. It won't interrupt your
code at all (like a Unix signal). It should be safe.
This archive was generated by hypermail 2.1.4 : Thu Aug 08 2002 - 09:37:27 EDT