On 05/18/2013 04:05 PM, Patrick Walton wrote:
On 5/18/13 3:27 PM, Brian Anderson wrote:
* layout task places the response message payload into the 'oneshot'
buffer send by script.
* layout does an atomic swap with full fence to check the status of the
script task and sees that it is not waiting for the response message
(it's in the work queue).
* layout goes to wait for the next message from script...
* layout context switches to the scheduler to recv the next request.
* layout (in scheduler context) does an atomic swap with full fence to
place it's ~Task pointer into the pipe buffer and discover that no
message is available. Layout is now blocked.
* the scheduler drops back into the uv event loop.
* the scheduler wakes up later in response to the idle callback.
* the scheduler takes the work queue lock.
* the scheduler takes the script task out of the work queue.
* the scheduler drops the work queue lock.
* the scheduler context switches to the script task.
* the script task (as part of the unoptimized try_recv) context switches
*back* to scheduler context to recv.
* the script task (in scheduler context) does an atomic swap with full
fence and sees that the response payload is available
* the script task context switches back to its own context and takes the
response payload.
Is it possible to optimize this path by introducing a dual atomic
send/recv primitive that allows the script task to place its ~Task
directly into the port it's going to receive on instead of placing it
back into the work queue? This would save the trip through the idle
callback.
It would prevent the script task from doing anything useful while
layout is running, such as GC, but maybe it's worth it for layouts
that are predicted to be short. (In Servo today the script task does
have an idea of how much damage it's going to cause, so this could be
tuned.)
Yes, I think this is possible.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
