From: Dominique Martinet <email@example.com>
To: Karl Dahlke <firstname.lastname@example.org>
Subject: Re: can we quit patching quickjs?
Date: Wed, 17 Aug 2022 09:28:36 +0900 [thread overview]
Message-ID: <Yvw2ND/DUWLnIKT2@codewreck.org> (raw)
Karl Dahlke wrote on Tue, Aug 16, 2022 at 07:40:49PM -0400:
> Folks, I had a clever, and somewhat frightening, and somewhat ugly
> thought, but no uglier that patching and building quickjs ourselves.
> I can enqueue a job manually, just as promise does, then scan the
> runtime structure to see what has changed.
> This is, hopefully, the location of the jobs queue.
Hm, I had quickjs "2020-11-08 release take 2" and the offset for me was
280, so a bit off the mark from the 64-256 range.
With current quickjs master it moved to 288, I'm not sure what's
different with you.
The code does get the right offset though, we can also just extract the
offset from libquickjs.a if we build it ourselves as the default build
will have -g (packages will often strip debug infos, so we lose that
possibility if there ever is a package...)
$ pahole -y JSRuntime libquickjs.a | grep job_list
struct list_head job_list; /* 288 16 */
(which says it's offset 288 alright)
With that said, I can't say I like it but JS_EnqueueJob only changes the
job_list in that struct so it should be safe enough with a slightly
I didn't follow as closely as I should have, reading the comments it
looks like we need this because we share the same js context between
sessions and don't want to run timers in the background, right?
I recall this was done to share the common startwindow code, because
it's a bit slow to setup for every session?
I remember trying to play around precompiling it so we'd just need to
copy a blob for new inits, but I don't remember how that ended; at some
point we might just as well give up on mucking around with quickjs
internals and allocate a context par session if possible...
next prev parent reply other threads:[~2022-08-17 0:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-16 23:40 Karl Dahlke
2022-08-17 0:28 ` Dominique Martinet [this message]
2022-08-17 0:43 ` Karl Dahlke
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).