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. 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.
Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
