[edbrowse-dev] timers and async

[edbrowse-dev] timers and async

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 3916 bytes --]

This is just me thinking out loud in the middle of the night; you can ignore it.

Now that threads work and we sort of understand them, what can we do with them?

Javascript does some stuff using timers, and I already have to throttle them back so they don't run every 50ms or whatever,
cause I'm just not as fast as chrome with its compiled js, (yes compiled), and I'm never going to be that fast,
so high speed timers push the load average up to 1 and literally lock you out of interacting with edbrowse,
and ok let's assume that is done -
still -
sometimes a timer runs and does an xhr, and you hit return, and you have to wait for that timer to finish before you get anything.
Maybe it's just a second or 2 but it feels weird.
worst case, server could fail and you wait 20 seconds for the http connect timeout.
What if the javascript timer ran in another thread?
You could look around and read the site, just like a sighted person could see the screen while more stuff was happening in the background.

Ok but there are some problems.
duktape is not threadsafe, it says so clearly in the programmers manual.
One and only one thread can run js at a time.
The next timer does not run until the last one is finished.
And you can't run js in any way until the last timer is finished.
In jdb, the expression you want to evaluate doesn't happen until the timer is finished.
Pushing a button, even typing an entry into an input field, has to wait,
because that field might have oninput or onchange etc that runs javascript.
When you try to do any of these things I call a blocker to wait for the timer to finish.
Well that's no worse than we are now, because if a timer runs in the foreground you have to wait for it to finish before you do *anything*,
even read the page, so we're not giving up anything it's just some really careful programming that could lead to subtle irreproducible bugs,
and has a whole bunch more code that has to run in a background thread, not just curl and httpConnect.

Is all that worth doing?
Probably not, timers run fast and you usually don't notice, but here's another thing.

Some sites have asynchronous scripts.
They can run whenever, maybe pulling in ads or analyzers or metrics or whatever,
and you shouldn't have to wait for them.
Right now they are just scripts, and they have to load and run before you see the page.
The easiest way to implement an asynchronous script is to put it on a timer and let timers run asynchronously.
In other words, if I had already implemented timers, then async scripts would piggy back on that.
You wouldn't have to wait for the script to run, or even load!
It just goes in the background and you look around at the page, and yes, after the script runs the page might change,
and edbrowse will tell you, and you can look at the lines that changed, or not, as you prefer.

If on a timer, these scripts would run *after* all the onload code, and I don't know if that's right.
I mean I might spend a month implementing all this and feel good about it, and then that one site comes along with an async script
that can run separately from the other scripts, but still has to run before the onload code,
and then I'm screwed, cause we have to wait for the script to run before the onload code, before you see the page,
and all that work didn't gain us a damn thing.
So it would be nice to *know* if async scripts can run after the page is loaded, and after the onload code,
but I don't even know how to ask the question.

More complications:
if a timer or async script is running in the background,
and you do something heavy handed like ^ or q or ub or et or rf or something that tears down the entire window,
that timer has to finish first, or it will be operating on structures that have been freed,
and you know that will lead to seg faults.

Ok that's enough rambling for now.

Karl Dahlke