When we close the JS compartment we try and cancel all callbacks so that
they do not fire after the compartment is closed. However if we have
in-train callbacks, they can gum up the closedown and so we need to check
and if we've done all we can, we break out of the callback removal loop.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
This reduces the source complexity of the html_mouse_action()
previously this was a single function of several thousand
lines with over 30 local variables allocated on the stack.
Variables are now mostly held in a single static structure which
drasticaly reduces the size of stack frame required and improves
lookup locality.
The generated code does cause two additional function calls as the
compiler avoids inlining the sub functions. The optimiser seems to
produce somewhat better code within the sub functions.
In the final analysis there appears to be no significant performance
loss or gain with this change, just more readable source.
In order to better model content close vs destroy, add the concept
of closing a thread to the JS interface.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Since it makes more sense for the htmlc to be responsible for
when the JS thread gets destroyed, move its lifetime from the
responsibility of the browser window to the html content.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
In order to cope with threads which manage to navigate entirely
while executing (sadly possible) we need to handle the possibility
that a thread is destroyed by the browser but still needs to live
until it returns from whatever exec it was doing at the time.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Update the duktape bindings and dukky interface to support the
new JS heap/thread split. Heaps may have multiple active threads
though in general there will only be 2 at a time.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
In preparation for proper splitting of Javascript support into
heaps and threads, this renames the types and corrects the no-js
builds to still work. At this time no substantive change in
semantics exists, and the duktape build won't work.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>