edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] Object identifiers
Date: Sun, 23 Jul 2017 20:52:38 -0400	[thread overview]
Message-ID: <20170623205238.eklhad@comcast.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]

As you know, we use the pointer to the object as the link between that object in the js world and the corresponding html tag in the edbrowse world.
We did this in Mozilla, and naturally carried it across to duktape.
The documentation guarantees these pointers are valid, as long as the object is not garbage collected away.
We've come to learn that's a mighty big if.
I wrote a fair amount of code to make sure we weren't diddling with an object that was thrown away, because you get a seg fault if you do. Boom!
But then there's a bigger problem.
I'm sure this was present in mozilla, but we never got far enough down the road to see it.
tag1 links to object1 by pointer1, and javascript removes object1, and it is thrown away, and creates object2, which happens to use the same pointer1.
It passes pointer1 back to edbrowse, which already has this recorded in tag1.
So now tag1 is linked to object2, which may be a form instead of a div, may have different number of children, etc etc.
It is potentially bad, with unpredictable behavior, and nearly impossible to reproduce.
We went down the pointer path because neither engine gives you an unambiguous handle to the object.
So now I'm writing more code to know that object2 is new, and even if it uses pointer1, which we have in our registry, we should delete that tag and make a new one,
and I already broke edbrowse in a mysterious way, and it's just badbadbad.
So I'm thinking instead, why don't we create our own IDs.
Just a sequence number that we put on every object we care about, and an array to map back from sequence number to the object.
A bit of overhead, but no crashes if we accidentally reference an object that is gone, and no ambiguity - one object per id.
Change jsobjtype from voidd * to int, and systemically change everything else accordingly.
A fair chunk of work, but might be worth it.
I really don't have a better alternative right now. What do you think?

Karl Dahlke

             reply	other threads:[~2017-07-24  0:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-24  0:52 Karl Dahlke [this message]
2017-07-24  1:04 ` Chris Brannon
2017-07-24  5:25 ` Dominique Martinet
2017-07-24  6:43   ` Karl Dahlke
2017-07-24  7:49     ` Dominique Martinet
2017-07-24  7:03   ` Karl Dahlke
2017-07-24  5:43 ` Robert Ransom
2017-07-24 17:45   ` Adam Thompson

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=20170623205238.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    /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
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).