On 10/12/2013 05:01 PM, Lars Bergstrom wrote:
This was a great example and great find! After talking with Brian, I've opened
Rust issue 9831 (https://github.com/mozilla/rust/issues/9831 ) to track the
scheduler changes to make this code work.
What we can do in Servo right now is to start from a normal task instead and
spawn the constellation from there, spawning the special compositor thread
separately (instead of as the root task). We believe that should work around
the problem.
The reason we get any parallelism with code running inside an iframe is that
the task creation stuff I added to handle supervision and unlink failure also
caused those to get run on a separate scheduler instead of blocking inside of
the root scheduler associated with the main task.
OK, I looked at this closer and there is another problem. Besides the
one I mentioned previously about tasks spawned from the main thread
getting serialized to another thread, there's another problem with the
main thread trying to steal work. The main scheduler, which is a
single-threaded (non-work-stealing) scheduler is advertising itself as
eligible to steal work; this happens through the 'sleeper list', which
is a stack of schedulers that are currently sleeping, with no work to
do. What is taking place is: the main thread pushes itself to the
sleeper list, another scheduler wakes it up to steal, the main thread
steals a task, finds it can't run it, sends it to another scheduler,
pushes itself to the sleeper list, repeat. Essentially, most of the task
stealing that's taking place is getting serialized through the main
thread that can't actually run the task. This PR should fix the problem:
https://github.com/mozilla/rust/pull/9857
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
