fix: deadlock between FindComponents and updates of rendered components

[egil]

Fixed #577.

THIS is experimental.

My idea was to, instead of using a lock around the the render tree getting build and find component's traversing the render tree to find components, is to just run the find component logic inside the dispatcher for the renderer. That should ensure that only at the time is allowed to happen.

Pull request description

PR meta checklist

• Pull request is targeted at main branch for code
  or targeted at stable branch for documentation that is live on bunit.dev.
• Pull request is linked to all related issues, if any.
• I have read the CONTRIBUTING.md document.

Code PR specific checklist

• My code follows the code style of this project and AspNetCore coding guidelines.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly.
• I have updated the appropriate sub section in the CHANGELOG.md.
• I have added, updated or removed tests to according to my changes.
  • All tests passed.

[egil]

I need to pressure test this more. But after sleeping on this I am more confident in the solution than yesterday ☺️

[linkdotnet]

Just to recap why this is a better solution than the lock:

• We enter FindComponents from the dispatcher (let's call it UI-thread)
• Now if we have async code we return to the test-runner
• In case of WaitForXXX the magic happens: As this gets triggered via the UI thread we have blocking behavior and don't need the lock.

[linkdotnet]

I guess to some degree also the lock in WaitForXXX can be deleted.
Especially when the initial OnRender check is also done by the UI thread. We just have to enforce that

[egil]

I guess to some degree also the lock in WaitForXXX can be deleted. Especially when the initial OnRender check is also done by the UI thread. We just have to enforce that

I have been testing the changes with the code RaphaelMarcouxCTRL provided, and did run into another deadlock that was caused by the call to OnAfterRender(this, eventArgs.Empty); after the subscription to renderedFragment.OnAfterRender. With it stil their, his test failed almost instantly, without, I just ran it 100 times in a loop without issue.

That said, I still think the lock in WaitForHelper is needed, since there is a timer that runs in a different thread that could trigger a clean up/dispose of the WaitForHelper, at the same time as a OnAfterRender check is being processed.

[egil]

OK, so the latest fix does cause other tests to fail consistently. Ill keep experimenting 🤕

[egil]

Just to recap why this is a better solution than the lock:

• We enter FindComponents from the dispatcher (let's call it UI-thread)

• Now if we have async code we return to the test-runner

Not really, since FindComponents are synchronous all the way through, meaning that it will complete without ever being async.

It's just a way for us to schedule the FindComponents call on the same scheduler as the renderer. If you look at Renderer.cs you will see they use a similar trick in there as well.

• In case of WaitForXXX the magic happens: As this gets triggered via the UI thread we have blocking behavior and don't need the lock.

There is a race condition between the timeout timer and the OnAfterRender updates. But a lock might be too heavy and something else could be used to say "don't dispose while there is an OnAfterRender check in progress, and don't start a OnAfterRender check after dispose has started".

[egil]

Ps. I will rewrite the commit when things looks like they are working

[egil]

@linkdotnet I think this is it. Let me know if you can spot anything wrong with this.

I could not figure out a way to actually test that the renderer is blocked while FindComponents is doing its thing. Did test it manually by having a component constantly re-render and adding a thread.sleep to FindComponents, and can see that without forcing FindComponents to run in the same context as the renderer, the constant rerendering component doesnt stop.

[linkdotnet]

Good work on this one. Especially the WaitForHelper is IMHO more readable.