From mboxrd@z Thu Jan 1 00:00:00 1970 X-Greylist: delayed 488 seconds by postgrey-1.37 at hurricane; Sun, 25 Oct 2020 22:46:39 PDT Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 7EB8977887 for ; Sun, 25 Oct 2020 22:46:39 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id WvDCkPLo1dQwjWvDCkFTGs; Mon, 26 Oct 2020 05:38:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1603690710; bh=bQ74LVj0tvc8jFGvF1xOH7NyFJcFtZ3mm36HlnN7A+M=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=zUcE+so/uBdEF/iWpYo/4fO6A6x7lOX+3cfEaH9Opl6jK5QQqxsE6V61P6Pqubaeh 9L3PD0ey0I88DFRm6cre0FRUx3aPnV2kWRZiMBSs3ke6cIZcVWrlA3DoaYU5jO1ICr rRwAs1ClNI70bLcejclNfd5y0EhMPiD/TzIDl6A4Fm3MfQVhyi6jjFDO7fXR3hCWBf pwrPOwW04P3huAG5OO64dOeC9ZyrDxzIfVLDtYYj4hfatm9/6v6Vav6oCmDJAaWMcT Y9XhidInXf0aOcOlybrk6X+u2Y5uCf3NRH1urxIW6p2a64AIdyIdmHVv3qk2d9gEk0 qEwdZwjwSssjA== Received: from unknown ([IPv6:2601:408:c300:a3d0::32fe]) by resomta-ch2-09v.sys.comcast.net with ESMTPSA id WvDAkG7gQSpt7WvDBktTWW; Mon, 26 Oct 2020 05:38:30 +0000 X-Xfinity-VMeta: sc=0.00;st=legit To:edbrowse-dev@edbrowse.org From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.7.6 Subject: [edbrowse-dev] Why Date: Mon, 26 Oct 2020 01:38:28 -0400 Message-ID: <20200926013828.eklhad@comcast.net> X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-673635 Content-Transfer-Encoding: 7bit This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --nextpart-eb-673635 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I need to think outloud on this one. You don't have to reply. We set up a rather complex and duktape specific system to notify us = when an object is feed, and kill the corresponding edbrowse tag, if = there is one, t->dead =3D true. Why? Why was this necessary? I ask because none of the other engines that we might consider seem to = have the hooks to do this. I'm looking all through mozjs and there seems no way to get my fingers = into the garbage collector, no way to know when an object is freed. And yet, I rather remember edbrowse core dumping because it was = accessing an object that was breed. Instead of wondering how or why this might happen, we built this = feedback system, which other engines might not support, so again let's step back and ask why. Look at the rerender system, to redraw the page. It starts at document and goes through the tree depth first, but the = edbrowse tree and the js tree are always in sync. They are as long as js uses appendChild and removeChild and = insertBefore and all those good things to rebuild its tree. And it's suppose to, it is not proper DOM to just create objects and = hang them on the tree; you're suppose to use these primitives; so if = you do, then these trees should be in sync. Every object hanging off of every tag in our tree should be valid, = since that is an object in the javascript tree under document. Obviously there's a lot more going on besides rerender. What about clicking on a link? We access the object on that tag. When we rendered that page, the tag was still there because the object = is there. The object would only go away if js rearranged the tree, which it = should be doing with appendChild and the like, and shouldn't we know = about it? That could happen on a timer I suppose, and perhaps we didn't rerender = the page yet. But I sort of remember the core dump even without this timer complexity. When submitting or reseting forms, we sweep through all the tags to = look for input elements on this form. Maybe some of them are gone. Or we sweep through all the tags looking for options under a select. I'd probably have to check every sequential search through the tags, = rather than a tree search, to see what it is doing and if that could be = trouble. So it might be time to stop looking at engines for a bit, and look at = the structure of edbrowse, and ask how or why we needed this free-object kill-tag system. Karl Dahlke --nextpart-eb-673635--