edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: edbrowse-dev@edbrowse.org
Subject: [edbrowse-dev] Why
Date: Mon, 26 Oct 2020 01:38:28 -0400	[thread overview]
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 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:

* 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 \


* 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).