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

  • From: Ondřej Jirman <deibeemoocheuguhumoh@xxxxxx>
  • To: quickjs-devel@xxxxxxxxxxxxx
  • Date: Thu, 19 Sep 2019 20:11:12 +0200

Hi,

On Thu, Sep 19, 2019 at 07:46:06PM +0200, 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?

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

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.

Why not have different runtimes per-thread? If compilation overhead is
an issue, you may pre-compile to bytecode once, and then just load the
bytecode.

Anyway, if you like to play with fire, I don't think it's enough to sync
on gc(), just look at JSRuntime struct, there's a ton of other shared
data there, that you'll have hard time synchronizing, like obj_list,
atom_hash, etc.

regards,
        o.

greets

maG

PS:

Involved API interface: JS_EnqueueJob(), JS_IsJobPending(),
JS_ExecutePendingJob()





Other related posts:

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