DRAIN_EXCLUSIVE_ACTIONS implementation

[steve-the-edwards]

Add an option to get the next action that is mutually exclusive to the dirty nodes. Then we can apply as many of those actions as possible.

Add tests for this as well and ensure existing tests can run with this runtime config on.

[zach-klippenstein]

I don't understand the interaction between conflation and drainExclusive. It looks like we run the drainExclusive loop first, then render, then conflate, drainExclusive, and render, etc. Wouldn't we want to continuously interleave drainExclusive and conflation passes? Or is that what we're doing and I just can't read code?

[zach-klippenstein]

At the risk of over-optimizing, this could be a value class to avoid allocating RenderingProduced objects every pass even when they're ignored.

[steve-the-edwards]

nice. will take a look at doing this.

[steve-the-edwards]

I'd have to talk more with you about what you are thinking. I am not sure we even need to report the rendering itself to the interceptor. I can start by just removing that?

[steve-the-edwards]

Well, that object is already allocated (probably why I was not worried originally). So we could start by just making RenderingProduced a value class I think I was confused originally because this comment was on the RuntimeUpdate sealed interface

[steve-the-edwards]

I made RenderingProduced a value class now. The others are just objects, so this should all be quite fast / have minimal allocations.

[zach-klippenstein]

There's no point in making a subclass of this a value class, since it will be boxed when referred to as a parent type. We'd need to replace the entire sealed class/interface hierarchy with a single value class.

[steve-the-edwards]

Oh, interesting!

[zach-klippenstein]

Nit: You shouldn't need the backticks here, you're not using spaces or other illegal characters.

[steve-the-edwards]

It's actually because this is KMP code that runs on js as well, IIRC. For some reason the kotlin-js compiler can't handle long names that don't have ticks? Or maybe that's why I had to add the _. Now I can't remember. But it was something with kotlin-js.

[steve-the-edwards]

Turns out I was just remembering wrong or had copied this forward when not needed. Removed now!

[steve-the-edwards]

I don't understand the interaction between conflation and drainExclusive. It looks like we run the drainExclusive loop first, then render, then conflate, drainExclusive, and render, etc. Wouldn't we want to continuously interleave drainExclusive and conflation passes? Or is that what we're doing and I just can't read code?

the main loop (after the first synchronous render) is:

1. awaitAndApplyAction() for the first available action
2. DEA loop: Drain any exclusive actions immediately available - synchronously for any actions already queued (no suspend here).
3. render()
4. CSR loop: Drain any other actions immediately available; render() after each one.
5. pass updated rendering down the StateFlow.

No interleaving is necessary from what I can tell. The exclusive actions for DEA are just a subset of the actions that can be applied without rendering at all.

[mannydelgado]

Should we be checking the selfStateDirty here as well?
is there in which the self state might be dirty but the subtree isnt?

[steve-the-edwards]

no. if self is dirty, subtree is also dirty. Not true the other way around though, subtree may be dirty without the self being dirty.

[zach-klippenstein]

Subtree includes self, basically.

[rjrjr]

I don't understand the interaction between conflation and drainExclusive. It looks like we run the drainExclusive loop first, then render, then conflate, drainExclusive, and render, etc. Wouldn't we want to continuously interleave drainExclusive and conflation passes? Or is that what we're doing and I just can't read code?

the main loop (after the first synchronous render) is:

1. awaitAndApplyAction() for the first available action
2. DEA loop: Drain any exclusive actions immediately available - synchronously for any actions already queued (no suspend here).
3. render()
4. CSR loop: Drain any other actions immediately available; render() after each one.
5. pass updated rendering down the StateFlow.

No interleaving is necessary from what I can tell. The exclusive actions for DEA are just a subset of the actions that can be applied without rendering at all.

It'd be good to capture this in a comment in the code.

[zach-klippenstein]

I don't understand the interaction between conflation and drainExclusive. It looks like we run the drainExclusive loop first, then render, then conflate, drainExclusive, and render, etc. Wouldn't we want to continuously interleave drainExclusive and conflation passes? Or is that what we're doing and I just can't read code?

the main loop (after the first synchronous render) is:

1. awaitAndApplyAction() for the first available action
2. DEA loop: Drain any exclusive actions immediately available - synchronously for any actions already queued (no suspend here).
3. render()
4. CSR loop: Drain any other actions immediately available; render() after each one.
5. pass updated rendering down the StateFlow.

No interleaving is necessary from what I can tell. The exclusive actions for DEA are just a subset of the actions that can be applied without rendering at all.

Why would exclusive actions only be available after (1) and not after (3)?

[steve-the-edwards]

I don't understand the interaction between conflation and drainExclusive. It looks like we run the drainExclusive loop first, then render, then conflate, drainExclusive, and render, etc. Wouldn't we want to continuously interleave drainExclusive and conflation passes? Or is that what we're doing and I just can't read code?

the main loop (after the first synchronous render) is:

1. awaitAndApplyAction() for the first available action
2. DEA loop: Drain any exclusive actions immediately available - synchronously for any actions already queued (no suspend here).
3. render()
4. CSR loop: Drain any other actions immediately available; render() after each one.
5. pass updated rendering down the StateFlow.

No interleaving is necessary from what I can tell. The exclusive actions for DEA are just a subset of the actions that can be applied without rendering at all.

Why would exclusive actions only be available after (1) and not after (3)?

We chatted offline and realized I need to make a few things much more clear in the code:

• we only have new actions to process when we suspend which only happens with 1 .
• the DEA loop will do nothing when using an immediate dispatcher where the select will return 'immediately' after the first action is available. We need to use a fairer dispatcher to get multiple actions to drain.
• We don't need to run the DEA loop after 4 (after CSR action handling) again because there was no suspension there so there are no new DEA actions ready to be processed.