Do such events always cause the layout task to require DOM access to create the flow tree? If so, the layout task would still have to wait for the script task to finish, meaning that layout still can’t occur unless forced by script.
Cameron On Aug 28, 2014, at 7:10 PM, Patrick Walton <pwal...@mozilla.com> wrote: > It might happen if layout is flushed from outside the script task; window > resizing/device rotation being what immediately comes to mind, as today in > Servo those events go straight from compositor to layout without hitting the > script task at all. (As an alternative design, we could route such events > through the script task; this would remove the necessity of the mutex but > would block layout for such events if script is running, even if the script > hasn't touched the DOM.) > > Patrick > > On August 28, 2014 7:05:09 PM PDT, Robert O'Callahan <rob...@ocallahan.org> > wrote: > On Fri, Aug 29, 2014 at 12:56 PM, Cameron Zwarich <zwar...@mozilla.com> > wrote: > > Is it strictly enforced that the script task never sees inconsistent views > of layout? This came up in the other thread about threading, but what > prevents this incorrect scenario? > > 1) The script task takes the mutex to access one property of layout. > 2) The script task releases the mutex. > 3) Layout changes the property that was accessed. > 4) The script task takes the mutex again to access the same property, in > the same turn of the event loop without modifying layout in any intervening > work since the last attempt. > 5) The script task reads a different value from before. > > > I'm confused. Before or during step 1, the layout must be brought up to > date (flushed, in Gecko > parlance). So step 3 shouldn't happen since layout > would already be fully up to date. > > Rob > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
