[squeak-dev] WorldState deferredUIMessages queue

> (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].

> 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.

> 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].
>

> 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
>
>

> Chris Muller wrote:
>>
>> Any advice is greatly appreciated.
>
> Actually, here is a fun test to exercise the problem:
>
> testDoOneCycleWorksWithDeferredQueue
>        "Ensure that nested doOneCycles don't break deferred UI messages"
>        | finished |
>        [
>                WorldState addDeferredUIMessage:[World doOneCycleNow].
>                WorldState addDeferredUIMessage:["whatever"].
>                World doOneCycleNow.
>                finished := true.
>        ] valueWithin: 1 second onTimeout:[finished := false].
>        self assert: finished
>
> Cheers,
>  - Andreas
>
>
>