[edbrowse-dev] Why

[Karl Dahlke <eklhad@comcast.net>]

[-- 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