Dom Lachowicz wrote:
>>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
>
>
>
Have you looked if there is code available in Free Software Land to
reuse? I'd look into that before starting such a (seemingly) huge project.
--
H�kan Waara ([EMAIL PROTECTED])
