[squeak-dev] Re: WorldState deferredUIMessages queue
Andreas Raab
andreas.raab at gmx.de
Tue Mar 24 22:18:01 UTC 2009
Bert Freudenberg wrote:
> On 24.03.2009, at 22:37, Andreas Raab wrote:
>> Chris Muller wrote:
>>> (3.9 Morphic). With Maui I occassionally get World lockups due to the
>>> UI process waiting for the #next of the deferredUIMessages, which is
>>> empty.
>>> Specifically, the freeze, when it occurs, is always in
>>> WorldState>>#runStepMethodsIn:. There's a while loop to process
>>> messages in the queue:
>>> "Dispatch deferred messages while maintaing rudimentary UI
>>> responsiveness."
>>> [i < numItems and: [(Time millisecondsSince: stamp) < limit]]
>>> whileTrue: [queue next value. i := i + 1].
>>
>> This is plain wrong. I don't know what the rationale of the change was
>> but you'll have much better success if you change this to e.g.,
>>
>> queue := self class deferredUIMessages.
>> [(msg := queue nextOrNil) == nil] whileFalse: [
>> msg value.
>> ].
>>
>> The reason why the original version is wrong is that there is
>> absolutely no assurance that some Morph won't call World doOneCycle
>> which would re-enter the above loop, pull out all of the events and
>> leave the original caller hanging; just as you report.
>
>
> FWIW, the 3.8 method looked like this:
>
> [queue isEmpty] whileFalse: [queue next value].
>
Which is not entirely safe either since there can a contention for the
queue inbetween #isEmpty and #next. We found this when we were still
using Morphic worlds in Croquet that would execute concurrently (bad
idea ;-)
Cheers
- Andreas
More information about the Squeak-dev
mailing list
|