With the Main.immediate dispatcher process side effects in time to drain multiple actions without yield().

[steve-the-edwards]

We use an inner loop for CONFLATE_STALE_RENDERINGS and DRAIN_EXCLUSIVE_ACTIONS (here) to apply multiple actions in one render pass (or in the case of CSR, in one 'UI update').

When the runtime is executed on the Main.immediate dispatcher, we handle one side effect of a worker update, and then render and try to process actions before the other workers (and their side effects underneath) have been able to be dispatched in order to send the other actions that need processing to the action sink.

This means that the optimizations like CONFLATE_STALE_RENDERINGS are much less effective with the Main.immediate dispatcher as we are not able to populate the actions that need processing as fast as we can process them.

We need to fix that! We have enshrined that desire in a currently ignored android test that uses the Main.immediate dispatcher.

[steve-the-edwards]

The reason we could not use yield() in the middle of a runtime loop update is we want to keep the semantics of "1 main thread message for 1 workflow update."

This does not meant that we can't yield() before processing the first action after resuming and knowing that it is ready.

See #1344

[rjrjr]

This does not meant that we can't yield() before processing the first action after resuming and knowing that it is ready.

I can read that as:

• resume
• click event
• yield
• process actions

Which would take us out of the tick of the click event, wouldn't it? Where am I getting confused?

[steve-the-edwards]

Which would take us out of the tick of the click event, wouldn't it?

Yes this is a great point. I need to only do this for Workers and/or possibly side effects if we give them a special action type.

[rjrjr]

and/or possibly side effects if we give them a special action type

If you were able to pull that off I think it might cover workers as well. But pragmatically, almost no one is posting actions from side effects.