Re: [Edbrowse-dev] JS1

[Adam Thompson <arthompson1990@gmail.com>]

On Fri, Jul 28, 2017 at 06:05:19PM -0400, Karl Dahlke wrote:
> > They're kind of authogonal and kind of not. With the separate process we can
> > keep spinning round the main input loop even if js is stuck in some expensive
> > operation.
> 
> In theory we could, but today we don't.
> I send a message over pipe to js process and block read waiting for a response.
> Things to consider though: 1. websites aren't going to write js code that computes a million digits of pi, at least not on purpose.
> I don't believe there are that many js expensive operations out in the wild.
> That's why I didn't mind waiting for the response.
> Second, I'm calling up the web page and I want to read the page, that is next on my list of things to do,
> I really don't want to go off to another buffer and do something else.
> If it's really that slow I'm going to be annoyed, whether I have the freedom to switch buffers while I wait or not.
> It just shouldn't be that slow.
> A measure of the quality of a mainstream browser is often how quickly it can bring up complex sweb pages.
> 3, so far the times it has been really slow is our fault, our DOM was not correct or complete and that caused js to go into a long loop, sometimes an infinite loop,
> and that wouldn't happen on another browser or on edbrowse if we had all our objects correct.

Agreed.

> Speaking of serialized poling and timers,
> one thing I had to do was scale back the intervals, so they can't fire 20 times a second,
> as they do on some sites for visual effects.

Since some of these timers aren't for visual effects (polling, checking that
aspects of the DOM are correct etc) I had a quick look at the timers code
yesterday.  I have a version of the code with the 10 ms minimum as per the spec
and I've altered the code to run a single timer then spin round the loop again.
This appears to work in testing since what happens is that we run one of the very
fast timers, call select again, detect that we don't have input and that we have
timers waiting then run the next one.  In the case that we have input we read it
then spin back round and catch the fact that we have timers pending.  I'm not
sure if this exposes any new corners but it's available in:
https://github.com/arthompson/edbrowse.git
I can push the changes into the edbrowse main repo if people are happy.

Cheers,
Adam.
PS: I'm now running js in 1-process mode so that's how I've tested it.  I've
spun it up in 2-proc mode but I've not extensively tested it.