[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