From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30804 invoked from network); 17 Aug 2022 00:29:10 -0000 Received: from hurricane.the-brannons.com (2602:ff06:725:1:20::25) by inbox.vuxu.org with ESMTPUTF8; 17 Aug 2022 00:29:10 -0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by hurricane.the-brannons.com (OpenSMTPD) with ESMTP id 2295687b for ; Tue, 16 Aug 2022 17:29:08 -0700 (PDT) Received: from nautica.notk.org (ipv6.notk.org [2001:41d0:1:7a93::1]) by hurricane.the-brannons.com (OpenSMTPD) with ESMTPS id 6550e981 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO) for ; Tue, 16 Aug 2022 17:29:00 -0700 (PDT) Received: by nautica.notk.org (Postfix, from userid 108) id E0F25C01A; Wed, 17 Aug 2022 02:28:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1660696135; bh=OwDpV02MpPd1Ogcs06Jj7pJ1jW3gyu19eWaUo20DX8o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=utkSLsd5ZPeQ/XDEhiPgez5hCti8DgT9uuzxpzzF+zDkMvJTc/yZvZBlZjdEji/ru V27fX9q/IOCDc+vaPIULpHNWKAI6I83uSu1tIeqAJlYYLX9D1B8id2Bv42SG24mCnU /E2BXeOvvCR4+B59bozcQHHT8aNnTxSPpBDAOtD0ngOPs3ZI3qaiLi1j12MQ+NzxYB Lmf0PRatxCz6Tf33nzw6CDXfU05mmhB44SqFKU/oQ5N+V19y7N0EtexTPyHnW0W87v 5ZHb1c8vLZNFt6KRgP5XdL6h3uIDsPd9KaZBL7Ju/BSWSSkRPBhObDdzLbUIvqO3i+ pKNGSuGNLlh/w== Received: from odin.codewreck.org (localhost [127.0.0.1]) by nautica.notk.org (Postfix) with ESMTPS id D96C4C009; Wed, 17 Aug 2022 02:28:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1660696135; bh=OwDpV02MpPd1Ogcs06Jj7pJ1jW3gyu19eWaUo20DX8o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=utkSLsd5ZPeQ/XDEhiPgez5hCti8DgT9uuzxpzzF+zDkMvJTc/yZvZBlZjdEji/ru V27fX9q/IOCDc+vaPIULpHNWKAI6I83uSu1tIeqAJlYYLX9D1B8id2Bv42SG24mCnU /E2BXeOvvCR4+B59bozcQHHT8aNnTxSPpBDAOtD0ngOPs3ZI3qaiLi1j12MQ+NzxYB Lmf0PRatxCz6Tf33nzw6CDXfU05mmhB44SqFKU/oQ5N+V19y7N0EtexTPyHnW0W87v 5ZHb1c8vLZNFt6KRgP5XdL6h3uIDsPd9KaZBL7Ju/BSWSSkRPBhObDdzLbUIvqO3i+ pKNGSuGNLlh/w== Received: from localhost (odin.codewreck.org [local]) by odin.codewreck.org (OpenSMTPD) with ESMTPA id 9c0359b9; Wed, 17 Aug 2022 00:28:51 +0000 (UTC) Date: Wed, 17 Aug 2022 09:28:36 +0900 From: Dominique Martinet To: Karl Dahlke Cc: edbrowse-dev@edbrowse.org Subject: Re: can we quit patching quickjs? Message-ID: References: <20220716194049.eklhad@comcast.net> X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220716194049.eklhad@comcast.net> 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 larger range...? 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... -- Dominique