I filed both of the issues discussed on this thread:
https://github.com/servo/servo/issues/3187
https://github.com/servo/servo/issues/3188
Cameron
On Aug 28, 2014, at 7:20 PM, Patrick Walton wrote:
> I believe the answer today is "nothing"--i.e. it's a Servo bug. Clark's work
> doubles as a n
On 8/29/14 5:27 AM, Lars Bergstrom wrote:
In general, I'd be a little wary of adding global locks into Servo
unless it's really necessary (i.e., if it turns out we can't
architect away the race condition Cameron brought up in any other
way). Since we haven't found a good way to do any concurrent
On 2014-08-29 9:52 AM, Josh Matthews wrote:
On 2014-08-29 8:27 AM, Lars Bergstrom wrote:
At that point, I'd expect script to layout calls via message passing
to be much cheaper than a mutex acquisition, but would be very
interested to see numbers comparing them!
To be clear, we're spawning a g
On 2014-08-29 8:27 AM, Lars Bergstrom wrote:
On Aug 28, 2014, at 9:26 PM, Cameron Zwarich wrote:
As a side point, why is there a 7 us overhead here for message-passing between
green threads? Is it really that bad? Are script and layout currently green
tasks, or did something land causing this
On Aug 28, 2014, at 9:26 PM, Cameron Zwarich wrote:
> On Aug 28, 2014, at 5:45 PM, Clark Gaebel wrote:
>
>> Running this on Firefox takes 500 ns/iteration. Chrome takes 700
>> ns/iteration.
>>
>> Servo before [1] lands took 8100 ns! That's paying a lot (some would say too
>> much) for a para
On Aug 28, 2014, at 5:45 PM, Clark Gaebel wrote:
> Running this on Firefox takes 500 ns/iteration. Chrome takes 700 ns/iteration.
>
> Servo before [1] lands took 8100 ns! That's paying a lot (some would say too
> much) for a parallel architecture, when simple queries experience a 10x
> slowdow
I believe the answer today is "nothing"--i.e. it's a Servo bug. Clark's work
doubles as a nice way to fix it :)
Patrick
On August 28, 2014 7:18:27 PM PDT, Robert O'Callahan
wrote:
>On Fri, Aug 29, 2014 at 2:10 PM, Patrick Walton
>wrote:
>
>> It might happen if layout is flushed from outside t
Good point. I believe that the answer is no in general, but there are special
cases in which the flow tree must be rebuilt at least in part. Normally the
flow tree can be reused on window resize/device rotation/CSS animation, but
there are special cases in which it can't (e.g. media queries). Bu
On Fri, Aug 29, 2014 at 2:10 PM, Patrick Walton 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 t
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 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 eve
On Fri, Aug 29, 2014 at 12:56 PM, Cameron Zwarich
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 pr
On 8/28/14 6:06 PM, Cameron Zwarich wrote:
I assumed that was the case, but was going to wait for his response before the
obvious follow-up question. We did a similar thing with iOS WebKit: a recursive
mutex that was only released on the turn of an event loop. It was universally
regarded as be
On Aug 28, 2014, at 6:00 PM, Patrick Walton wrote:
> On 8/28/14 5:56 PM, Cameron Zwarich wrote:
>> It’s nice that it’s so close to the competition. It would be interesting to
>> see numbers on ARM as well, since the relative cost of the atomic
>> instructions might be higher, even in the uncont
On 8/28/14 5:56 PM, Cameron Zwarich wrote:
It’s nice that it’s so close to the competition. It would be interesting to see
numbers on ARM as well, since the relative cost of the atomic instructions
might be higher, even in the uncontended case.
Is it strictly enforced that the script task neve
It’s nice that it’s so close to the competition. It would be interesting to see
numbers on ARM as well, since the relative cost of the atomic instructions
might be higher, even in the uncontended case.
Is it strictly enforced that the script task never sees inconsistent views of
layout? This ca
Hi servo-dev!
Servo exists to validate the idea that parallel browser architectures work.
Going parallel isn't always a good thing, and can sometimes be worse if there's
too much communication overhead. For example, in the current Servo design,
javascript is run in a different task than layout.
17 matches
Mail list logo
