From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) by hurricane.the-brannons.com (Postfix) with ESMTPS id A632C7893D for ; Sun, 23 Jul 2017 23:43:16 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id ZX5Vd5n6OGWg6ZX5Vd9Ik0; Mon, 24 Jul 2017 06:43:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1500878609; bh=3aLQGUSe7/JGMZNRpM/7Ff+gYbfoO0wzclULY3i5ESc=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=hPymiaS5omznUALw/M6hZiuLzqOq6lsejlz4GMMnQw7DC7gah/q4G2aW+UzxjM5tb iRM+t+SImk+kQUK3C1u7oEXeyYp0dMBVnkLMhFrH8Vp1mt+KLHwEzEeQeZxj9MiCpT tveEDDV4wfZWx3PUh4Yzu38FqNJmLv8RI6/qvi6QTzBLaHgpfLm4XOl1QrFrzxrt3B CKaCl7m3d/h+HJesVG+t5i0PMarllHl9GpuvUtnZbxoMgNeDenfCj8jiFoGgn8z4rz 1YKdwdfbzJQcrwcTZHLrzru1H9QhZMScvjnTHRsPjkjWQGALVVmxt+hgpLq1sPzHii /anNKyjXTW+9A== Received: from unknown ([IPv6:2601:408:c301:784d:21e:4fff:fec2:a0f1]) by resomta-ch2-03v.sys.comcast.net with SMTP id ZX5VdEs6aTnV3ZX5Vd6HzU; Mon, 24 Jul 2017 06:43:29 +0000 To: edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke References: <20170623205238.eklhad@comcast.net> <20170724052529.GB31626@nautica> User-Agent: edbrowse/3.7.0x Date: Mon, 24 Jul 2017 02:43:28 -0400 Message-ID: <20170624024328.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-012851 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfE77q9DD54Aqqs2rO5C7IqZpEQvTHy4Exxb7KXsvU60j0o3nH2m/1BaoAMJiV6FCrYlAjdnxs7Romc1rx68tCc/XrxxipApjtTdl5EiJHoCIv8FUOf7R He/EmH/TlOma7piLX5IEnYMB13upqjHge5Y/Ke8vEcWauXNIbZMwT6fs Subject: [Edbrowse-dev] Object identifiers X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 06:43:16 -0000 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-012851 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > I'm not quite sure it will help, if the problem is a desynchronisation > between what we think is still linked and what duktape thinks is = still linked Well if we call upon an object with id 17, and there is no such object, = for any reason, we get back eb$idl[17] which will not crash the = process, and is probably the null object, which is what we want. It won't have the properties we look for, and if we try to set = properties it won't do anything. But as Chris pointed out, it will never be garbage collected away, = because it always has at least one reference, our registry eb$idl[17]. That's good and bad. We can mess with extinct objects all we want, because they're still = there, but objects accumulate and never go away. Not until you close the window. Some web pages perform some kind of update every few seconds, like my = example http://www.eklhad.net/async and these would just accrue objects in js and tags in edbrowse for as = long as the page is open. I don't think my generated id plan is prohibitive, probably 2 or 3 days = work to get it functioning. There are advantages to that plan, and advantages to your free = interceptor. If I don't maintain a registry of objects then they will indeed go away = when they should. I only need wrapper free, because the pointer to the object is valid = until it is thrown away. But is the pointer returned by get_heapptr() the same as the base of = the allocated region for that object? Probably, but we really don't know. It could be a structure inside the region, so malloc and free would not = be the same pointers as get_heapptr and push_heapptr. Only way to know is to write a stand-alone test program. We'd sure want to do that before going down that path. And hope duktape never changed that internal design. So what to do when a pointer is freed? Since the heap holds everything, you have to loop through all tags in = all open windows in edbrowse, and if any tag has the pointer, and there should be only one, mark it = dead or otherwise delete it. Well that's not too awful, if JS1 is set and everything is one process. In the 2 process model it's a pain! At an unpredictable time while javascript is running, it frees some = object and we can see the pointer that is freed. But we're in the wrong process. I guess I'd need another side effect, pass the freed pointers back to = edbrowse along with the response to whatever js function ran. Then edbrowse can run its own version of gc as described above. > I also think most implementations will have a way to use our own > allocation functions I don't believe mozilla allowed for this. In other words, we couldn't have considered this approach last month. > What do you think? I tentatively like it - even though I just spent a few hours working on = the generated id design... Oh well. Karl Dahlke --nextpart-eb-012851--