On Sat, Apr 11, 2015 at 10:44:58AM -0400, Karl Dahlke wrote:
> There is another problem with my quick&dirty approach,
> running the short timers now and then returning control to the user.
> A timer that fires in 5 milliseconds,
> that I decide to run now, may well queue up another timer that fires in 5 ms.
> Well my software might figure: it's just 5 ms away, run it now.
> It queues up another timer in 5 ms, which I run, and so on,
> and suddenly I'm in an infinite loop and the user is locked out.

Ouch, I hadn't thought of that.
> Of course in any other browser this does something 100 times a second,
> in the background, without churning the cpu, and without locking
> out the user.
> So whatever we decide, it has to be a bit smarter than just:
> run the shor ttimers now and put the long timers under user synchronous control.
> Perhaps Adam's background model or some other model.
> Anyways I'm not going to mess with these for a while,
> until we can all give it a bit more thought.

Yeah, it's going to be a large change whatever we do.
If we do go to an async approach, it'd also be kind of nice to do what most
modern browsers do and fetch things in parallel as well.
That'd speed up page load times which,
whilst not my biggest concern with edbrowse,
are starting to get overly long with some more js-heavy websites.

Cheers,
Adam.