How to control on which thread an asynchronous function is run?

[handerss-spotfire]

I noticed that when awaiting asynchronous functions the thread which executes the script can switch.

Take for instance this program which uses the task-to-promise flag:

using Microsoft.ClearScript.V8;

namespace ClearScriptPlaygroud;

public class ScriptObject
{
    public Task<string> GetTheString()
    {
        return Task.Run(() =>
        {
            Console.WriteLine($"{nameof(GetTheString)} {Thread.CurrentThread.ManagedThreadId}");
            Thread.Sleep(5 * 1000);
            return "foobar";
        });
    }
}

internal class Program
{
    static void Main()
    {
        using var engine = new V8ScriptEngine(V8ScriptEngineFlags.EnableTaskPromiseConversion);

        engine.AddHostObject("obj", new ScriptObject());
        engine.AddHostType(typeof(Thread));
        engine.AddHostType(typeof(Console));

        Console.WriteLine($"Invoking on thread {Thread.CurrentThread.ManagedThreadId}");

        engine.Execute("script.js", @"
function foobar() {
    (async () => {
        Console.WriteLine(`Async before: ${Thread.CurrentThread.ManagedThreadId}`);
        const res = await obj.GetTheString();
        Console.WriteLine(`Async after: ${Thread.CurrentThread.ManagedThreadId}`);
    })();
}
");

        engine.Invoke("foobar");
        Console.ReadLine();
    }
}

Runnings this outputs:

Invoking on thread 1
Async before: 1
GetTheString 8
Async after: 8

Which shows that the script has switched threads. Is there a way to control which threads are used for executing the script?

[ClearScriptLib]

Hello @handerss-tibco,

Is there a way to control which threads are used for executing the script?

Your question really has to do with .NET task continuation handling. In principle, yes, .NET gives you control over how task continuation work items are queued and processed.

If you wish to route task continuation to a given thread, you need two things:

1. A way to post work items to the target thread, which must be running an event loop of some kind.
2. A SynchronizationContext that posts task continuation callbacks to your work queue.

.NET's Windows Desktop SDK includes the Dispatcher class, which neatly satisfies both requirements (see example below). On other platforms you'll have to implement something similar.

Note that, as written above – without an event loop – your code can't handle task continuation on the starting thread (thread 1); by the time the GetTheString result is available, thread 1 is stuck inside Console.ReadLine. Also, you're using Task.Run, which always sends work to the thread pool. Finally, GetTheString is effectively async, so something like Task.Delay is probably preferable to Thread.Sleep.

Let's start by making ScriptObject a bit more async-friendly:

public class ScriptObject {
    public async Task<string> GetTheString() {
        Console.WriteLine($"{nameof(GetTheString)} {Thread.CurrentThread.ManagedThreadId}");
        await Task.Delay(5 * 1000);
        return "foobar";
    }
}

Now let's do the same for your main test code and move it into a separate method for convenience:

static async Task Test() {
    using var engine = new V8ScriptEngine(V8ScriptEngineFlags.EnableTaskPromiseConversion);
    engine.AddHostObject("obj", new ScriptObject());
    engine.AddHostTypes(typeof(Thread), typeof(Console));
    Console.WriteLine($"Invoking on thread {Thread.CurrentThread.ManagedThreadId}");
    engine.Execute("script.js", @"
        async function foobar() {
            Console.WriteLine(`Async before: ${Thread.CurrentThread.ManagedThreadId}`);
            const res = await obj.GetTheString();
            Console.WriteLine(`Async after: ${Thread.CurrentThread.ManagedThreadId}`);
        }
    ");
    await (Task)engine.Invoke("foobar");
}

Invoking the test method directly produces a thread switch as before:

static async Task Main() {
    await Test();
}

Output:

Invoking on thread 1
Async before: 1
GetTheString 1
Async after: 5

But now we can use a dispatcher to get the desired behavior:

static void Main() {
    Dispatcher.CurrentDispatcher.BeginInvoke(new Func<Task>(async () => {
        await Test();
        Dispatcher.ExitAllFrames();
    }));
    Dispatcher.Run();
}

Output:

Invoking on thread 1
Async before: 1
GetTheString 1
Async after: 1

Please let us know if you have any questions or comments. Thank you!

[handerss-spotfire]

Thank you! I tested executing the script using a single threaded TaskScheduler and it worked as expected.

[handerss-spotfire]

So I got a bit of a follow-up here with regards to how the awaits in V8 interact with the SynchronizationContext (or rather that they don't). My use-case is that I want all script code and synchronous managed code to run with certain privileges and these privileges are tied to a thread (but can be moved via cooperation).

In a pure managed context it seems I can easily solve this by overriding the SynchronizationContext and force all SendOrPostCallback callbacks to run on a thread with the appropriate privileges (similar to how WCF and Forms do this). On each await in managed code a continuation is posted to the current SynchronizationContext and I can control on which thread this continuation is run. However, when awaiting in script code no continuation is passed.

Here's a .NET Fiddle which showcases the problem: https://dotnetfiddle.net/tqG7GL

Managed result:
has-privilege | Sync before
no-privilege  | Performing background work...
has-privilege | Sync after

Script result:
has-privilege | Sync before
no-privilege  | Performing background work...
no-privilege  | Sync after

Essentially the example boils down to that the following snippet produces different results when executed inside the script engine as javascript (same syntax) and when executed as managed code.

Util.EchoPrivilege("Sync managed code before");
await Util.PerformWork();
Util.EchoPrivilege("Sync managed code after");

I'm guessing this is expected since in managed code the await keyword compiles down to a state machine which properly checks for the synchronization context, while in V8 the Task <-> Promise conversion loses this.

Is there any way to achieve a similar result in ClearScript? It seems to me that when using a TaskScheduler I cannot know if the Task contains script code or managed code, otherwise that would be an option.

[ClearScriptLib]

Hi @handerss-spotfire,

I'm guessing this is expected since in managed code the await keyword compiles down to a state machine which properly checks for the synchronization context, while in V8 the Task <-> Promise conversion loses this.

That's essentially correct. ClearScript should be able to provide the desired behavior, but it'll probably require explicit enablement to preserve compatibility with previous releases. We'll take a closer look.

Is there any way to achieve a similar result in ClearScript?

In your example, try modifying PerformWork as follows:

public static Task PerformWork() {
    var task = new Task(() => {
        EchoPrivilege($"Performing background work...");
        Thread.Sleep(100);
    });
    task.Start();
    return task.ContinueWith(_ => {}, TaskScheduler.FromCurrentSynchronizationContext());
}

Good luck!

[handerss-spotfire]

Performing the continuation manually like that does seem to work. In my case PeformWork represents some existing method that should not be modified. A workaround however would be to tag such methods with NoScriptAccess and define some sibling method which schedules the continuation and exposing that method with the appropriate name via ScriptMember.

But an opt-in way to have SynchronizationContext "just work" would be useful.

[ClearScriptLib]

Version 7.4.4 added V8ScriptEngineFlags.UseSynchronizationContexts.