On Fri, 06 Aug 2010 15:30:42 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/6/10 4:04 AM, Philip Jägenstedt wrote:
See, this concept of a script is a funny one, given that scripts are
reentrant, and that multiple different scripts can all be running at
the same time, possibly with event
On Thu, 05 Aug 2010 17:22:17 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/5/10 5:14 AM, Philip Jägenstedt wrote:
It's not, in fact, trivial in implementation. You're making
assumptions about how implementations work that don't seem warranted
(e.g. the concept of reference to that very
On 8/6/10 4:04 AM, Philip Jägenstedt wrote:
See, this concept of a script is a funny one, given that scripts are
reentrant, and that multiple different scripts can all be running at
the same time, possibly with event loops nested in between on the
conceptual callstack
Well, what we really look
On Wed, 04 Aug 2010 19:19:35 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/4/10 6:56 AM, Philip Jägenstedt wrote:
On Wed, 04 Aug 2010 11:32:51 +0200, Boris Zbarsky bzbar...@mit.edu
wrote:
On 8/4/10 4:29 AM, Philip Jägenstedt wrote:
That could be, but is this behavior actually useful
On 8/5/10 5:14 AM, Philip Jägenstedt wrote:
It's not, in fact, trivial in implementation. You're making
assumptions about how implementations work that don't seem warranted
(e.g. the concept of reference to that very script is not
well-defined in some implementations). In particular, what you're
On Aug 5, 2010, at 8:22 AM, Boris Zbarsky wrote:
In practice, what Gecko would likely do here is to treat stable state as
the event loop is spinning, just like we would for the other case. This
means that while a modal dialog is up, or a sync XHR is running or whatnot is
a stable state.
On 8/5/10 2:24 PM, Eric Carlson wrote:
On Aug 5, 2010, at 8:22 AM, Boris Zbarsky wrote:
In practice, what Gecko would likely do here is to treat stable state as the
event loop is spinning, just like we would for the other case. This means that while a modal
dialog is up, or a sync XHR is
On Tue, 03 Aug 2010 17:40:33 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/3/10 4:27 AM, Philip Jägenstedt wrote:
For the record, here's how I interpreted await a stable state:
The only state that is not stable is a running script.
I don't think that's true; for example you could be in
On 8/4/10 4:29 AM, Philip Jägenstedt wrote:
That could be, but is this behavior actually useful for anything? It's
certainly simpler to implement and more predictable for authors to
always wait until the current script has finished executing.
1) That requires defining current script.
2) Who
On Wed, 04 Aug 2010 11:32:51 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/4/10 4:29 AM, Philip Jägenstedt wrote:
That could be, but is this behavior actually useful for anything? It's
certainly simpler to implement and more predictable for authors to
always wait until the current script
On 8/4/10 6:56 AM, Philip Jägenstedt wrote:
On Wed, 04 Aug 2010 11:32:51 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/4/10 4:29 AM, Philip Jägenstedt wrote:
That could be, but is this behavior actually useful for anything? It's
certainly simpler to implement and more predictable for
On Tue, 03 Aug 2010 00:40:26 +0200, Chris Pearce ch...@pearce.org.nz
wrote:
On 2/08/2010 9:17 p.m., Ian Hickson wrote:
On Mon, 2 Aug 2010, Chris Pearce wrote:
There's a race condition in the media load algorithm. When the resource
selection algorithm begins, it sets a task to complete the
On 8/3/10 4:27 AM, Philip Jägenstedt wrote:
For the record, here's how I interpreted await a stable state:
The only state that is not stable is a running script.
I don't think that's true; for example you could be in an unstable state
if you're in the middle of the parser inserting some
On 3/08/2010 9:20 a.m., Ian Hickson wrote:
The synchronous section would run as soon as the task span the event loop.
Spinning the event loop is defined essentially as being equivalent to
breaking the original task in two, one that does everything up to spinning
the event loop, and one that
On Wed, 4 Aug 2010, Chris Pearce wrote:
So the task spinning the event loop has run up to the point of spinning
the event loop, then we run the synchronous section, and then the task
which was spinning the event loop will resume after its goal is met at
some later time?
Sounds right.
On 4/08/2010 11:32 a.m., Ian Hickson wrote:
In the case of a tasks which invokes an algorithm which has a
synchronous section, and then pauses the event loop (such calling
window.alert()), we should not run the synchronous section until the
event loop pause has completed?
Currently, yeah. We
On Mon, 2 Aug 2010, Chris Pearce wrote:
There's a race condition in the media load algorithm. When the resource
selection algorithm begins, it sets a task to complete the rest of the
resource selection algorithm asynchronously.
Not quite. It awaits a stable state and then runs a synchronous
On 8/2/10 5:17 AM, Ian Hickson wrote:
There's a race condition in the media load algorithm. When the resource
selection algorithm begins, it sets a task to complete the rest of the
resource selection algorithm asynchronously.
Not quite. It awaits a stable state and then runs a synchronous
On Mon, 2 Aug 2010, Boris Zbarsky wrote:
So the model is that there are asynchronous tasks but there are also
things that run after the current asynchronous task finishes?
It's a little more detailed than that, but yes, that describes the event
loop model.
How are we defining current
On 8/2/10 3:11 PM, Ian Hickson wrote:
How are we defining current asynchronous task and finish?
In terms of the event loop algorithm:
http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#processing-model-2
Ah, I see. Is the note there about synchronous sections
On Mon, 2 Aug 2010, Boris Zbarsky wrote:
On 8/2/10 3:11 PM, Ian Hickson wrote:
How are we defining current asynchronous task and finish?
In terms of the event loop algorithm:
http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#processing-model-2
Ah, I
On 2/08/2010 9:17 p.m., Ian Hickson wrote:
On Mon, 2 Aug 2010, Chris Pearce wrote:
There's a race condition in the media load algorithm. When the resource
selection algorithm begins, it sets a task to complete the rest of the
resource selection algorithm asynchronously.
Not quite. It awaits a
On 8/2/10 5:20 PM, Ian Hickson wrote:
Or does stop the currently running task in #spin-the-event-loop imply
a jump to step 2 of the algorithm under #processing-model2?
Yes.
OK, that might be worth clarifying.
(Note: I still have a problem with the way pause is defined here, but
I've raised
There's a race condition in the media load algorithm. When the
resource selection algorithm begins, it sets a task to complete the rest
of the resource selection algorithm asynchronously. In the asynchronous
task, we set the delaying-the-load-event flag to true at step 4. But
between the
24 matches
Mail list logo
