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>
If we fail to init the control file for reasons other than it
not being found, we blow away the cache in its entirety and then
try again. We warn if the removal fails, but carry on regardless
since right now the worst that'll happen is that we'll end up
with more on disk than we know about in the cache.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
If we are aborting a cURL fetch then it's possible entry to
cURL to clean up could cause a PROGRESS message to happen which
we need to not reset last_msg for, otherwise we spuriously attempt
to send an ERROR message during abort which is not a safe time for
our message callback to be used.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
This simplifies the poll loops a little more and makes me less worried
that some other corner case will bite us in the future.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
When aborting a fetch, it may be cleaned up, in which case we
would otherwise send a spurious failure message too early. Instead
we record that the abort has occurred to suppress such an error.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Because cURL can do connection caching behind the scenes, we
need to have a cache for the SSL certificate chains which we
send onward on first header back from cURL.
This uses the new hashmap implementation to mean that we cache
chains on a hostname:port basis.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
As a result, we no longer waste a bunch of RAM on the entries
tables. This ought to be no slower, and more memory efficient.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Instead of extracting information from the X509 certificate chain in
the fetcher the entire chain is propagated in Distinguished Encoding
Rules (DER) format.
This allows all the information contained in a certificate chain to be
retained which can subsequently be presented to the user
