Event Loop and async code

[SebastianStehle]

Hi,

I think the idea with the event loop is the chance to make jint somehow ready for the async world. I am not talking about async-await just about some code that is invoked later when a condition has been met.

I am talking about callbacks, promises and real async/await code. I try to understand how promises work, but I have my problems with that. Therefore I am trying to start from beginning.

At the moment, the execution mode of jint is linear. Therefore when Execute returns we assume that all code that should have been run has been executed. Of course this does not work with callbacks anymore, so we need a way to define when we are done.

For my understanding we are done when all jobs in the event loop have been executed successfully. We could create an async method for that and just complete a TaskCompletionSource when the event loop is empty.

The idea of the event loop should be to schedule some code to be executed at a later point of time. When the code is executed, is the responsibility of the extension or function that uses delegates.

If I understand it properly this is exactly how RegisterPromise works.

But I see a few problems or questions:

1. The event loop is not thread safe, therefore it probably does not work with async code well enough.
2. The promise is not registered in the event loop, therefore we don't know how many promises we have and when we are done with execution.
3. I think we should have some kind of exit function to get out of the task.
4. The event loop does not reset the constraints. I think there should be a timeout constraint that only measures the code spent within jint, not waiting and async callbacks.

[lahma]

Let' not forget that JavaScript is single-threaded 😉 , but pinging subject matter expert @twop for insights into discussion.

[SebastianStehle]

Yes, but only within the event loop. The actual calls to the scheduler could come from another thread. E.g. if you have a rendering thread and a scripting thread.

But this aspect is not that important, I just wanna make safe async calls in my functions.

[lahma]

I think Jint will be thread-unsafe for a long time. It's not that easy to make it tread-safe, but locking around the engine of course works.

[twop]

But this aspect is not that important, I just wanna make safe async calls in my functions.

Maybe I'm missing something but you can do that today with RegisterPromise. However, you have to complete them on the same thread, or at least not in a concurrent way.

So today this workflow is possible:

1. Expose a function to JS that creates a promise.
2. When that function is called store the info about the call somewhere (I use a List for that in my project)
3. After Execute is finished, you have a list of calls that need to be resolved. Note that before this point we were only on the same thread as JS execution.
4. Go through the list and start execution promises, note that you can go ham in terms of parallel execution of these, that is how browsers actually fulfill them. But there is a catch! (see next point).
5. When you finish promises, they run a piece of JS code that was awaiting them (e.g. in promise.then(() => "that code there")), thus it needs to be done on the same thread as we were creating them in Execute call. Note that this continuation can create new promises, so it is kinda resembles a recursion a bit.
6. You are done when Execute is finished and there are no pending promises.

So in short, you can execute promises in whatever thread you wish with whatever async primitives are available to you, BUT you need to continue execution (when you fulfill them) on the same thread.

I think I wrote a helper that does exactly that a while back, that does all the steps and works on top of existing API (e.g. can be done completely outside of Jint). @lahma do you remember where that snippet was?

I acknowledge that following these steps can be tedious, but remember that Task does not map directly into Promise, even though they look very similar on the surface. Thus I personally would consider creating async API in Jint a bit more advanced use case that requires understanding of the nuances of both systems. On the bright side, you can just use the helper (by copy pasting it to your project), and it will probably cover most of the friction points.

[SebastianStehle]

Yes, you are right. I want to solve point 1. and point 6. For me it feels weird that I can "jump back into the script" after Execute has been completed. I am already using async code and callbacks but it took me a while to understand how to write it properly with jint. Having a simple approach for that for all developers could be helpful.

[EnCey]

5. thus it needs to be done on the same thread as we were creating them in Execute call

Hope it's ok if I'm asking this here:
what exactly does Jint need when you say "on the same thread", is it just the .NET ExecutionContext, or really the thread?

I plan to run Jint on a server where I'm not sure I can guarantee that the Engine sticks to a single thread. (haven't looked at ConfigureAwait(true) in detail yet, but I think it doesn't guarantee to use the same thread)

I know from prior experience that I can capture & restore the ExecutionContext, which means all ThreadLocal variables the Engine uses are restored on whatever thread it is used – so I'm wondering, is this the only reason why we need the same thread, or is there more?

[lahma]

I think the general rule it that you cannot access the engine concurrently - engine is not thread-safe. So you can have tasks and threads going on but the engine access/evaluation should be single threaded/having locks.

[twop]

On other points you made such as

The event loop does not reset the constraints. I think there should be a timeout constraint that only measures the code spent within jint, not waiting and async callbacks.

When I was working on adding Promises my goal was to ship MVP, I believe the current version might have rough edges in terms of tracking and timeouts. Specifically because fulfilling promises are essentially the same as calling Execute but follow a slightly different path (if I recall correctly). Thus, some of the features might be either not implemented or not accessible. Would be awesome if you can provide a list of not implemented features, so we have the exact scope to tackle.

[twop]

Related discussions: #935

Also found a snippet that I made a while back: https://gist.github.com/twop/8d7b849d0105c779eed87bff8ae59722

Note that the code in the snippet is designed to live outside of Jint core. Thus feel free to copy and modify directly into your project.

If I recall correctly @lahma wanted to take it and package it as a separate NuGet. Am I dreaming that this conversation happened ^_^ ?

[lahma]

If I recall correctly @lahma wanted to take it and package it as a separate NuGet. Am I dreaming that this conversation happened ^_^ ?

Feels like years ago 😉 I think it was a Gitter discussion about mostly about offering some sort of automation through API without the need to explicitly run continuations. Unfortunately didn't act on it when I still had a slight understanding about my idea..