Le 13/08/2013 06:07, David Herman a écrit :
On Aug 12, 2013, at 6:32 PM, David Bruant bruan...@gmail.com wrote:
How do people recover today from when the user click stop script?
They don't; it's a crash -- the web equivalent of this application has stopped
responding. You might as well ask
On Aug 8, 2013, at 7:09 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Aug 8, 2013 at 3:03 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
To me the answer always seemed obvious: use the slow-script dialog. What am
I missing?
That seems like a bad answer. Slow-script
On Aug 8, 2013, at 2:08 PM, K. Gadd k...@luminance.org wrote:
Why is the slow script dialog box even relevant for setImmediate? As I
understand it, setImmediate is equivalent to DoEvents in Visual Basic/Windows
Forms and pumping the message loop in a normal C application. That is, you
can
Wait, what? The semantics of the web demands that runaway JS block any other
even turns, or page layout/rendering from proceeding. Multi-process browsers
can prevent cross-origin pages from interfering with each other, and Servo
can do speculative layout to reward well-behaved pages, but
On Aug 12, 2013, at 5:40 PM, François REMY francois.remy@outlook.com
wrote:
I don't think of you as unimaginative, but I think there are other options.
:)
Sure, there must be a way to kill a script that's burning your CPU but it
doesn't have to be a dialog.
That's fine, I guess I
On Aug 12, 2013, at 5:43 PM, David Bruant bruan...@gmail.com wrote:
- I see *no* reasonable alternative to runaway microtask churn other than
slow-script dialog.
So did Dominic [1]. I suggested something else [2] and he found the idea
interesting. What do you think?
Quoting you from
[2]
FWIW,
I very much agree with Dave on this point. My conceptual model for
microtask work is just a re-ordering of work which otherwise would
have run synchronously, but wanted to be run with a fresh stack.
Microtask non-termination should not be different from regular
script non-termination.
On
Le 13/08/2013 03:09, David Herman a écrit :
On Aug 12, 2013, at 5:43 PM, David Bruant bruan...@gmail.com wrote:
- I see *no* reasonable alternative to runaway microtask churn other than
slow-script dialog.
So did Dominic [1]. I suggested something else [2] and he found the idea
interesting.
On Aug 12, 2013, at 6:32 PM, David Bruant bruan...@gmail.com wrote:
How do people recover today from when the user click stop script?
They don't; it's a crash -- the web equivalent of this application has stopped
responding. You might as well ask for a solution to the halting problem! :)
Dave
David Herman wrote:
On Aug 12, 2013, at 6:32 PM, David Bruantbruan...@gmail.com wrote:
How do people recover today from when the user click stop script?
They don't; it's a crash
(safe of course -- I'm a C hacker at heart :-P)
-- the web equivalent of this application has stopped
On 08/08/2013, at 15:55, David Bruant wrote:
This is not a Trying to protect us from ourselves situation. This is a
browser trying to protect users from any sort of abuse situation. For while
loops, they implemented the script takes too long dialog. For mistakenly
infinitely nested too
: EcmaScriptmailto:es-discuss@mozilla.org
Subject: Re: setImmediate
On 08/08/2013, at 15:55, David Bruant wrote:
This is not a Trying to protect us from ourselves situation. This is a
browser trying to protect users from any sort of abuse situation. For while
loops, they implemented the script takes too
2013/8/8 David Bruant bruan...@gmail.com
2) A way to run a function after the current microtask and before
yielding back to the browser, same as what Object.observe() does. This is
what we need for promises and other library features that depend on some
level of asynchronicity and deal with
The clamping inside nested callbacks prevents setImmediate from being as good
at this job as postMessage or MessageChannel
Er, prevents setTimeout(..., 0) from being as good...
___
es-discuss mailing list
es-discuss@mozilla.org
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
From what I understand, setTimeout 0 serves that use case and there is no
reason for setImmediate to be better at this job.
This is not true, as can be seen from
http://domenic.me/setImmediate-shim-demo/. The clamping
On Thu, Aug 8, 2013 at 3:03 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
To me the answer always seemed obvious: use the slow-script dialog. What am I
missing?
That seems like a bad answer. Slow-script dialogs are a misfeature.
They only exist because otherwise single-threaded
Le 08/08/2013 16:03, Domenic Denicola a écrit :
This is not a Trying to protect us from ourselves situation. This is a
browser
trying to protect users from any sort of abuse situation. For while loops,
they implemented the script takes too long dialog. For mistakenly infinitely
nested too short
Slow-script dialogs are a misfeature.
As I see it, what we want out of the method that browsers handle infinite loop
like code is:
1. Something which has the minimum possible impact on well designed pages.
2. Something which will gracefully kill badly designed pages before they break
the
Le 08/08/2013 16:43, Forbes Lindesay a écrit :
Also, on the point about draining the battery, using very short
timeouts is terrible for battery life but using `setImmediate` is
considerably better.
Why so?
David
___
es-discuss mailing list
Right, +1 to both of Forbes's points.
I think the essential equivalence I want to get across is between microtasks
(`window.asap`) and synchronous loops. If there is a better solution than the
slow-script dialog for such scenarios, great! Maybe we can use it in future
APIs like `window.asap`,
Why so?
I think it was something Domenic Denicola said that I'm remembering, but don't
the extremely short timeouts mean more work (and thus power) for the CPUs
timer. I'm sure I remember reading something about timeouts less than a
certain amount using additional power.
If I'm wrong (which
From: Forbes Lindesay [for...@lindesay.co.uk]
Why so?
I think it was something Domenic Denicola said that I'm remembering, but
don't the extremely short timeouts mean more work (and thus power) for the
CPUs timer. I'm sure I remember reading something about timeouts less than a
certain
Le 08/08/2013 16:03, Domenic Denicola a écrit :
To me the answer always seemed obvious: use the slow-script dialog.
What am I missing?
Maybe implementations could decide to break a microtask chain, but
instead of prompting a dialog, they just break it and call a callback
(later, in a different
Hmm, interesting!
I wonder if it could be event simpler than that, and after an arbitrary limit
(in time, not number of microtasks), just reschedule for the next event loop
turn's microtask phase. For promise applications there is no problem with this;
I am not sure however if that is an
tl;dr - I would simply fix `setTimeout 0` ^_^
long story long:
from a suer perspective, I never understood why `setTimeout(fn, 0,
arguments)` does not act as `setImmediate(fn, arguments)` where latter one
is apparently needed to indeed replace a misleading behavior with first
`setTimeout` broken
Le 08/08/2013 17:00, Domenic Denicola a écrit :
Hmm, interesting!
I wonder if it could be event simpler than that, and after an arbitrary limit
(in time, not number of microtasks), just reschedule for the next event loop
turn's microtask phase. For promise applications there is no problem
On Thu, Aug 8, 2013 at 9:40 AM, David Bruant bruan...@gmail.com wrote:
Small delays between (micro)task sounds like a local maximum it's hard to
get away from unfortunately :-(
What if, instead of a slow script dialog, browsers responded to
microtask/setTimeout(0) abuse with gradual throttling?
Le 08/08/2013 22:04, Jason Orendorff a écrit :
On Thu, Aug 8, 2013 at 9:40 AM, David Bruant bruan...@gmail.com wrote:
Small delays between (micro)task sounds like a local maximum it's hard to
get away from unfortunately :-(
I think I was wrong here when it comes to microtasks.
Microtasks
Why is the slow script dialog box even relevant for setImmediate? As I
understand it, setImmediate is equivalent to DoEvents in Visual
Basic/Windows Forms and pumping the message loop in a normal C application.
That is, you can use setImmediate to make your application run as fast as
possible
29 matches
Mail list logo
