[quickjs-devel] Re: another stupid question about the pending job queue..
- From: Mario Gliewe <mag@xxxxxxxxx>
- To: quickjs-devel@xxxxxxxxxxxxx
- Date: Thu, 19 Sep 2019 20:24:30 +0200
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.
I didn't really had overhead or memory constraints in mind, it was more
for the sake of having a consistent API..
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.
I am digging in the code for some time now, and I am very impressed how
little of code adjustments would be necessary..
Its just pretty solid code. impressive.
greets
maG
On 19.09.19 20:11, Ondřej Jirman wrote:
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:
