From: Dom Lachowicz (doml@appligent.com)
Date: Sun Aug 04 2002 - 21:13:39 EDT
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/gtk/gtk-general.html#GTK-TIMEOUT-ADD-FULL
> Not quite. Requiring threads in AbiWord is a significant extra
> requirement on the hosting OS and a potential portability issue. We
> don't even have a threads implementation for Windows. As I noted above
> we gain nothing for a threads implementation of a blink.
And at one point in time Win32 didn't have an about dialog. Yet it got implemented somehow. Threads are not a significant requirement to make on an OS, as everything more developed than a Palm Pilot has thread support. Threads could be extremely useful for a bunch of contexts in our code.
> Don't be sorry Dom. It's a useful discussion. My main objection is the
> use of threads for a case that doesn't need them. I think we don't need
> to do anything as complex as Mike's full cursor class if we invent a
> class that manages to do the right thing when hit with a clearCursor()
> method. If the cursor class *always* knows the state of the cursor and
> we make sure we do a clearCursor() method before any screen manipulation
> I think we can come up with a better solution than the one we have now.
This is a much better argument. Your priority list is well-intentioned, but telling Pat what to do with his free time wasn't cool.
To get back on topic, threads aren't technically needed for this, nor are they necessarily the best solution for this particular problem. I've suggested that it would be trivial to reimplement this class in terms of a timer. However, I'd make a much different argument for the background spell checking block.
I think that we can and need to come up with a better solution than the one we have now.
Dom
This archive was generated by hypermail 2.1.4 : Sun Aug 04 2002 - 21:21:31 EDT