[quickjs-devel] Re: another stupid question about the pending job queue..

  • From: Fabrice Bellard <fabrice@xxxxxxxxxxx>
  • To: quickjs-devel@xxxxxxxxxxxxx
  • Date: Mon, 23 Sep 2019 19:35:00 +0200

On 9/19/19 7:46 PM, Mario Gliewe wrote:

Hi again,

I found another step stone to stumble over :)

In the JSRuntime there is this job_list, one has to take care on the
context's eventloop (via JS_ExecutePendingJob()) ; so don't terminate
the loop until all jobs are done.

As far as I could see, this is only used to fulfill/reject Promises..

While this concept seems reasonable (afaik that's what the node.js
setImmediate() would do), I was wondering why the Timers in quickjs-libc
wouldn't use this mechanism?

It is better to keep the timer list separated in case we want to sort it
for efficiency reasons (although it is not sorted yet !).

And I was wondering why this list is bound to the JSRuntime rather to
the JSContext?

All the job queues are defined per runtime. JSContext is here in case
the user wants several global objects, which is only useful in practice
in web browsers.

The reason I stumbled over this, was again the Worker-Interface, because
I cannot use the same runtime for different contexts in seperate threads
with this approach.

Even if I guarantee to never use the same JSValues across different
threads and synchronize gc(), the pending jobs would be executed in the
main-thread anyway.

There is no way you can run the code of a single JSRuntime at the same
time in different threads. For a Worker like interface you must
instantiate several JSRuntime and serialize objects between them. You
have an example of it in run-test262.c:js_agent_start(). I'll probably
add a more generic Worker example in quickjs-libc.c.

Best regards,

Fabrice.

Other related posts:

  1. Home
  2. quickjs-devel
  3. Archive
  4. 09-2019