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 _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
