What are nesting factories used for?

[weltkante]

I'm currently studying the codebase to evaluate how useful a port of the deadlock resolution to async frameworks on different runtimes would be and am a bit confused on the purpose of nestingFactories.

From what I can tell they contain a set of JoinableTaskFactory of its ambient tasks. This is calculated whenever a JoinableTask is launched.

The publically visible call sites to code which consumes nestingFactories are SynchronizationContext.Post and SwitchToMainThread. The usage of nestingFactories seems to be that it will post to any UnderlyingSynchronizationContext in the hierarchy of ambient tasks.

So whats the point of all this effort? It is optimized to not allocate in the common case of only having a single JoinableTaskFactory, so obviously there is some issue with having multiple TaskFactories it tries to solve? There are two scenarios I can think of that lead to having multiple factories:

• Creating multiple instances of JoinableTaskFactory for the same JoinableTaskContext (including JoinableTaskCollection)
• Creating multiple instances from distinct JoinableTaskContext (different UI threads?)

Since UnderlyingSynchronizationContext forwards to the JoinableTaskContext the first case does not really solve any issues does it? It just posts multiple times to the same SC, so it actually is an unnecessary performance overhead if anything, isn't it? I'd have expected the set of nesting JoinableTaskContext to be stored, not the set of nesting JoinableTaskFactory.

If the factories are for different UI threads then I'm wondering if this code is even correct in the first place, why would it post to every underlying thread when targeting a specific JoinableTask? Doesn't this basically mean code can run on arbitrary threads which happen to be in the chain launching a JoinableTask?

So, any idea what the nesting factories code is there for? Any scenario it actually helps with?

[AArnott]

FYI @sharwell actually did port this to Java several years ago. At least, I think he did, but now I can't find anything on an Internet search to back that up.

[weltkante]

I happened to run across it, in case anyone else is interested: https://github.com/tunnelvisionlabs/java-threading

(Google finds it while Bing doesn't - seems Bing needs to improve its github indexing)

[AArnott]

Creating multiple instances from distinct JoinableTaskContext (different UI threads?)

This is not the reason. Multiple instances of JoinableTaskContext never talk to each other. If you have two threads in the process that each have a single-threaded SynchronizationContext applied, then conceivably two JoinableTaskContext instances may apply in that process, but they will not communicate and deadlocks may result if any code needs both threads to complete.

I'd have expected the set of nesting JoinableTaskContext to be stored, not the set of nesting JoinableTaskFactory.

There is no such thing as nested JoinableTaskContext. The contract is to have exactly one for a designated thread.

You may create multiple JoinableTaskFactory instances, and those factories vary not only in which JoinableTaskCollection they may be associated with but also (and importantly for the point of nestingFactories) in priority of how they get to the UI thread.
Consider WPF, which has a Dispatcher by which you can schedule work with a variety of priorities back to the dispatcher thread. You can represent each of these priorities with a different JoinableTaskFactory instance using a derived type of that class that overrides the method responsible for calling SynchronizationContext.Post to instead call Dispatcher.InvokeAsync with some preset priority.
When a JoinableTask requires the main thread, we want to get it there with the highest priority found within itself and any parent JoinableTasks.

You can see tests related to nested factories and this priorities scenario starting with this one (and others nearby in that file):

vs-threading/test/Microsoft.VisualStudio.Threading.Tests/JoinableTaskTests.cs

Lines 2686 to 2705 in f578222

	public void NestedFactoriesCombinedMainThreadPolicies()
	{
	var loPriFactory = new ModalPumpingJoinableTaskFactory(this.context);
	var hiPriFactory = new ModalPumpingJoinableTaskFactory(this.context);
	JoinableTask? outer = hiPriFactory.RunAsync(async delegate
	{
	await loPriFactory.RunAsync(async delegate
	{
	await Task.Yield();
	});
	});
	// Verify that the loPriFactory received the message.
	Assert.Single(loPriFactory.JoinableTasksPendingMainthread);
	// Simulate a modal dialog, with a message pump that is willing
	// to execute hiPriFactory messages but not loPriFactory messages.
	hiPriFactory.DoModalLoopTillEmptyAndTaskCompleted(outer.Task, this.TimeoutToken);
	}

[weltkante]

Thanks, the explanation is very much appreciated.

I now see that I missed DispatcherJoinableTaskFactory when analyzing call chains because it was disabled via #if in the build I was looking at. Also was relying too much on VS for navigating the source, maybe should have done a text search to find comments/tests. Embarrassing mistakes.