On Sat, 18 Nov 2000, Christopher Plymire wrote:
>
> Thomas has informed me that the BeOS thread / timer issue has been
> covered on the list, so I won't get the discussion started all over
> again.
>
> Basically, all I want to know is that if it would be reasonable, until
> a proper fix for the timer bugs are introduced, to add a lock around
> the timer fire call under BeOS? This would prevent more than one
> thread from drawing a document currently being modified, such as when a
> keypress event occurs.
>
> The keypress event occurs in the view thread, so when a refresh is
> currently taking place a line deletion causes a hard crash when the
> refresh thread redraws the deleted line.
>
> The fix I propose:
>
> static BLocker ThreadLocker;
>
> In function _Timer_Proc
>
> + if( ThreadLocker.Lock() )
> + {
> pTimer->fire();
> + ThreadLocker.Unlock();
> + }
>
> I don't see any reason why this can't be implemented as a temporary
> fix, and I also belive that releasing a new version under BeOS without
> either the timer bugs fixed or this patch would be a mistake.
>
> Thoughts?
>
This seems a like a sensible thing to do however watch out for code that
manipulates the timer in the call-back code. The Spell Checker
does this. Does ThreadLocker poll a member variable until it becomes true
or does if just give up on that event?
I think we should also put locks around all the Public pieceTable
Manipulations in pd_Document.cpp. This is not much code and will make Abi
mostly thread safe. I say mostly because there might be calls somewhere
that by pass pd_Document and go striaght to the PieeTable. If so we should
hunt them down and replace them with calls through pd_Document.
Anyway I'm off bugfixing the select-all - paste bug.
Martin
