Re: [Edbrowse-dev] Object identifiers

[Dominique Martinet <asmadeus@codewreck.org>]

Hi,

Karl Dahlke wrote on Sun, Jul 23, 2017:
> I really don't have a better alternative right now. What do you think?

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 then even with an indirect mapping we still will have pointers to
invalid memory, unless you plan on using duktape to handle the map
itself.


I've had a look at duktape documentation and code, and I have an idea
that might be less code.
The duk_create_heap function lets us provide alloc, realloc and free
functions - we use it with duk_create_heap_default which is
duk_create_heap with a lot of NULL parameters but we can override some
of the base functions.

If we overload malloc, realloc and free with just a little wrapper that
tells the main edbrowse process "this address changed" (for realloc) or
"this address is no longer valid" (for free), nothing to do for malloc,
then we will have a safe way to determin a pointer can no longer be
used.

This is not as implementation-generic as making our own ID, but it
sounds like a _lot_ less work and should be safe for us.
I also think most implementations will have a way to use our own
allocation functions too so it might be more reuseable than it looks.


What do you think?

-- 
Dominique