PATCH: API to put maximum time limit on timers/intervals
Reported by nickg | March 5th, 2010 @ 07:17 PM
Loading a page that uses setIntervals never returns control or might return control after really long time. For instance, try loading my dorky website http://client9.com/ for instance. The "blinking cursor" is done by a js setInternal that repeats forever.
It would be nice to have some API to set a maximum time limit on "how long the page runs".
Not sure I completely understand how the source code is laid out, but the following patch basically does:
If there is another event/interval
and If Env.maxTime is defined and > 0
and if the now() + interval is past Env.maxTime
then exit
Problems:
- No nice way of reseting "when the page started" (could be hacked with $timers.first = Date.now())
- $timers.first is set when env.rhino.js is loaded, NOT when document is fully loaded.
- I doubt "maxTime" is the best name, and a default could be added to plaform/core.js as well.
Thoughts? Or should I use the group for this type of stuff?
+++ b/src/timer/timer.js
@@ -10,6 +10,7 @@ var $timers = [],
$timers.lock = function(fn){
Envjs.sync(fn)();
};
+$timers.first = Date.now();
//private internal class
var Timer = function(fn, interval){
@@ -169,6 +170,13 @@ Envjs.wait = function(wait) {
}
}
});
+
+ // exit if next event occurs past the maximum allowed time (if any)
+ if (earliest && Envjs && Envjs.maxTime > 0 && (earliest.at >= ($timers.first + Envjs.maxTime))) {
+ EVENT_LOOP_RUNNING = false;
+ return;
+ }
+
//next sleep time
sleep = earliest && earliest.at - Date.now();
if ( earliest && sleep <= 0 ) {
Comments and changes to this ticket
-
Steven Parkes March 10th, 2010 @ 06:28 AM
I think the event loop already has this functionality, in that wait can be called with a maximum amount of time to wait. The bigger issue then is how to get the overall driver which is calling wait to call the event loop with a value. Right now, I believe it always calls it with no value which means 'wait forever'.
-
nickg March 15th, 2010 @ 12:24 PM
Hi Steve,
I think you are right about the event loop. The problem is the "README" says the caller (you), is suppose to manually call Envjs.wait() after the initial parse. Unfortunately, Envjs.wait() is in the code in a few places. Maybe they should be pulled out.
Hmmm.....
-nickg
-
Steven Parkes March 15th, 2010 @ 12:44 PM
There are a couple of places where there are waits to support the parser, which does some things async (in order to support document.write). Those generally call wait with a -1 parameter.
There are a couple of new places in the 1.2 code base that call wait w/o that parameter, which with the 1.1 timer, would cause an unending wait if any intervals or infinitely rescheduled timers were been set. But I'm not too familiar with the 1.2 changes.
The async nature of the parser has been a bit of a challenge: it has a lot of corner cases, a number of which we haven't hit, I suspect.
-
nickg March 15th, 2010 @ 12:53 PM
Hi again,
I don't know if it's your domain or not, but you might find ticket 107 interesting:
http://envjs.lighthouseapp.com/projects/21590/tickets/107-on-page-w...Also, can one set a flag to make the parser synchronous? In my app, I don't need the async, and might make the app a bit more straightforward?
thanks!
--nickg
-
Steven Parkes March 15th, 2010 @ 01:11 PM
There's code that makes the parser sync to handle innerHTML, which can't have script tags and so can't do document.write.
As far as I know, there's no way to set that externally.
Might not be a good idea though ... the parser's tricky, so if there are other ways to achieve what's needed, they might be better.
-
nickg March 15th, 2010 @ 01:14 PM
Ok this gives me some ideas on how to make global timeout really easy.
Seem like it might be as simple as replacing
Envjs.wait();with
Envjs.wait(Envjs.MAXTIMEOUT_OR_SOMETHING);If it doesn't exist, then it's the same behavior. If it does, then use it.
I'll play around and report back.
-
nickg March 21st, 2010 @ 02:47 PM
- State changed from “new” to “open”
- Assigned user set to “nickg”
- Title changed from “API to put maximum time limit on timers/intervals (patch)” to “PATHC: API to put maximum time limit on timers/intervals”
Turns out actually is easy, with almost no code change (again thanks to the groundwork already laid -- thank you). This is the spot to change.
var __exchangeHTMLDocument__ = function(doc, text, url){ var html, head, title, body, event; try{ doc.baseURI = url; HTMLParser.parseDocument(text, doc); var t0 = Date.now(); // ignore Envjs.wait(1000); <---------------------- HERE var t1 = Date.now(); // ignore console.log("Post Parse MS: %d", (t1-t0)); // ignore }catch(e){Any thoughts on the constant to use?
Envjs.TIMER_MAX_ELASPEDand what if any default value should be used?thanks all,
--nickg
-
nickg March 21st, 2010 @ 02:48 PM
- Title changed from “PATHC: API to put maximum time limit on timers/intervals” to “PATCH: API to put maximum time limit on timers/intervals”
-
Steven Parkes March 21st, 2010 @ 05:02 PM
- Tag cleared.
Can you try changing the wait() to wait(-1)?
This got changed very early in the refactor, so there's no history in git. I'm not sure if there was a problem that was happening that dropping the argument helped or if it was inadvertent.
The reason wait accepts negative arguments is just for this case ... I'd like to at least try to get it back in. If something's broke, I can try to fix it.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
a javascript browser environment
nickg