Engine InvokeAsync is implemented for task/valuetask structure

[baytekink]

Engine InvokeAsync is implemented for task/valuetask structure

[baytekink]

What did I do : Remove ManualResetEvent, instead TaskCompletionSource is added. So we give the thread back to thread pool. After that, I added new methods for InvokeAsync, I generally copied the sequantial code and convert it into Task structure. Most of the components/classes uses sequantial methods, but JintAwaitExpression or JintAwaitxxx classes override the async methods. I may call ...Async methods from the sequantial ones (using GetAwaiter().GetResult()), but I did not do that, so we can discuss if we call Async methods by GetAwaiter().GetResult() or do we copy the nearly same code with ...Async ending method.

[SebastianStehle]

I will give you a bonus if this does work and would make async calls easier. But I am afraid it will kill performance. Have you added a benchmark and have you considered ValueTask?

[baytekink]

Thanks Sebastian, if you will give a chance, I will work with ValueTask if possible for performance, and would improve the code. I did not add any benchmarks cause I did not work enough on this (I suspect if you reject my work actually, so I dont want to work much on this 🙂 ) Hence, if you are serious about adding native Async, I will reengineer again about ValueTask, benchmark etc. Actually if we use await calls in javascript, Jint waits with ManualResetEventSlim, so it blocks the main thread. And awaited task is done with another threadpoolthread, so for one async call 2 threads are blocked :/ It decrease performance too much. But instead of this, If we wait with TaskCompletionSource, we would give the thread back to threadpool, so main thread will not be blocked. So 1 thread will work at a time instead of 2 thread. This is the main idea of this PR actually.

…

________________________________ Gönderen: Sebastian Stehle ***@***.***> Gönderildi: 2 Şubat 2025 Pazar 20:54 Kime: sebastienros/jint ***@***.***> Bilgi: baytekink ***@***.***>; Author ***@***.***> Konu: Re: [sebastienros/jint] Engine InvokeAsync is implemented for task/valuetask structure (PR #2049) I will give you a bonus if this does work and would make async calls easier. But I am afraid it will kill performance. Have you added a benchmark and have you considered ValueTask? — Reply to this email directly, view it on GitHub<#2049 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGES5V6SS6SOCGYYGAJV4DT2NZLVRAVCNFSM6AAAAABWDAAX5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMRZGQ4TCNBSHE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[lahma]

My main concern here is all the copy-paste, I'm not willing to maintain two copied versions. Also of course, performance should not degrade.

[lofcz]

A lot of the code currently copy pasted could be generated, I can look into that if the other issues are solved. Scriban also uses async code gen - shouldn't be too hard to implement (I've done similar work recently).

[baytekink]

My main concern here is all the copy-paste, I'm not willing to maintain two copied versions. Also of course, performance should not degrade.

Returning Task is changed by ValueTask for performance.

Duplicate methods reduced to single: While calling async code from sequantial code, Preserve() method is used for performance (This method is similar to [AsTask()], but it returns the same [ValueTask] instance when this [ValueTask] represents a successful synchronously completed operation ). For ex:

public JsValue Invoke(JsValue value, object? thisObj, object?[] arguments)
{
return InvokeAsync(value, thisObj, arguments).Preserve().GetAwaiter().GetResult();
}

If javascript code does not include any async/await code, this code will continue to work synchronously. The only difference it will create a ValueTask on stack. But it wont be a problem for GC since it was created on stack.

I have not found time to benchmark this code, I will try on this week, but while I try to benchmark, It would be nice if you could give comments on PR. Thx in advance

[baytekink]

I will give you a bonus if this does work and would make async calls easier. But I am afraid it will kill performance. Have you added a benchmark and have you considered ValueTask?

I now changed Task to ValueTask. Actually i do not think (I wrote think because teorically ValueTask wont be a problem since it is created on stack) it will decrease the performance, but we must see it by benchmarks of course. Thx in advance

[lahma]

Async state machinery will add a lot of strain for performance. So I wouldn't keep my hopes up with this async API...

[lahma]

We have a less invasive solution with #2274 now, hopefully it addresses the requirements without negative performance impact. Than you for the PR though, please propose improvements if still unaddressed.