FWIW The benchmark that I've done shows that there is no performance win by
spawning multiple tasks when top level task was started by
`start_on_main_thread()`:
https://gist.github.com/ILyoan/6945608
The output of the test implies spawning multi tasks from top level task
started on main thread doe
On Oct 11, 2013, at 2:55 PM, Brian Anderson wrote:
> On 10/11/2013 06:38 AM, Lars Bergstrom wrote:
> Unless there is a serious bug in the runtime (always possible), it's true
> that only the compositor task should be executing on the main thread, and
> every other task will be executing on other
On 10/11/2013 06:38 AM, Lars Bergstrom wrote:
All tasks should not be scheduled to run on the main thread: only the toplevel
one where the compositor runs. That design ensures the windowing system calls
(via glut and glfw) are performed on same system thread where the window was
created and th
Nobody is happy with how the whole DOM inheritance thing has turned out,
with the verbose callbacks like abstract.with_imm_elem(|elem|
elem.SetAttribute(...)). I'm planning to improve the status quo a bit in
two ways - by switching from callbacks to returning borrowed pointers,
and by performin
All tasks should not be scheduled to run on the main thread: only the toplevel
one where the compositor runs. That design ensures the windowing system calls
(via glut and glfw) are performed on same system thread where the window was
created and the windowing system was initialized, which is req
Dear all,
In order to test some parallel idea, I added a few tasks to layout task in
servo however I found that the tasks what I added did not run in concurrently.
they run with serialized. It looks to me that all tasks was bounded at single
thread and scheduled with std::rt::start_on_main_thr
6 matches
Mail list logo
