> Changing to a multithreaded application will be not much more work, it
> will
> be much *MUCH* more work.
>
> I remember stepping from here to there in the code several places where
> in a
> multithreaded environment can produce race conditions (the worst of
> these
> that I remember has to do with autosaving the doc).
>
> Note however, that it may be worth all that work.
Well, we are essentially in a MT environment anyway on *all* platforms. In the
BeOS case, they truely are in an MT environment, because their UT_Timer impl.
uses threads. Because of this, if Stephane Frisch types too quickly, Abi
crashes because of race conditions. There are more bugs like this that aren't
100% reproducible. I don't envy his situation.
Abi code already has *many* race conditions without our threads. Examples
include:
Autosave
Spellcheck
Cursor blinking
Undo/Redo
etc...
There is a *lot* of code that Martin has put into the text/fmt and text/ptbl
classes to deal with these sorts of things.
'isPieceTableChanging()'
'isCursorBlinking()'
Many places in our code has issues with the *current* timers, and right now
we're using (non-atomic) bools instead of atomic mutexes or semaphores.
This is an issue that we'll have to face sooner or later. The hacks are
already starting to add up. I'm willing to do a lot of the required legwork
here if other people are willing to help me. This might mean that we don't
release a 0.9.4 for a while. Even better would be if we put this off until
post 1.0 (but we could develop the XP mutex and thread classes before then).
I don't know what the proper solution here is, and I'm willing to hear
suggestions. This may or may not be worth the work we'd have to devote.
Dom
