From: Karl Dahlke <eklhad@comcast.net> To: edbrowse-dev@edbrowse.org Subject: [edbrowse-dev] Why Date: Mon, 26 Oct 2020 01:38:28 -0400 Message-ID: <20200926013828.eklhad@comcast.net> (raw) [-- Attachment #1: Type: text/plain, Size: 2423 bytes --] 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 = 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
reply other threads:[~2020-10-26 5:46 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200926013828.eklhad@comcast.net \ --to=eklhad@comcast.net \ --cc=edbrowse-dev@edbrowse.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
edbrowse-dev - development list for edbrowse This inbox may be cloned and mirrored by anyone: git clone --mirror http://inbox.vuxu.org/edbrowse-dev # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V1 edbrowse-dev edbrowse-dev/ http://inbox.vuxu.org/edbrowse-dev \ edbrowse-dev@edbrowse.org public-inbox-index edbrowse-dev Example config snippet for mirrors. Newsgroup available over NNTP: nntp://inbox.vuxu.org/vuxu.archive.edbrowse.dev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git