mirror of
https://github.com/servo/servo.git
synced 2025-08-06 22:15:33 +01:00
Auto merge of #18810 - asajeffrey:constellation-document-blocking, r=cbrewster
Document the can-block-on relationship for servo. <!-- Please describe your changes on the following line: --> This PR adds some documentation comments describing the can-block-on relation that is used to ensure deadlock-freedom. --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: --> - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix #14704 - [X] These changes do not require tests because it's documentation <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. --> <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/18810) <!-- Reviewable:end -->
This commit is contained in:
commit
4592e6e53a
1 changed files with 28 additions and 0 deletions
|
@ -64,6 +64,34 @@
|
|||
//!
|
||||
//! Since there is only one constellation, and its responsibilities include crash reporting,
|
||||
//! it is very important that it does not panic.
|
||||
//!
|
||||
//! It's also important that the constellation not deadlock. In particular, we need
|
||||
//! to be careful that we don't introduce any cycles in the can-block-on relation.
|
||||
//! Blocking is typically introduced by `receiver.recv()`, which blocks waiting for the
|
||||
//! sender to send some data. Servo tries to achieve deadlock-freedom by using the following
|
||||
//! can-block-on relation:
|
||||
//!
|
||||
//! * Layout can block on canvas
|
||||
//! * Layout can block on font cache
|
||||
//! * Layout can block on image cache
|
||||
//! * Constellation can block on compositor
|
||||
//! * Constellation can block on embedder
|
||||
//! * Constellation can block on layout
|
||||
//! * Script can block on anything (other than script)
|
||||
//! * Blocking is transitive (if T1 can block on T2 and T2 can block on T3 then T1 can block on T3)
|
||||
//! * Nothing can block on itself!
|
||||
//!
|
||||
//! There is a complexity intoduced by IPC channels, since they do not support
|
||||
//! non-blocking send. This means that as well as `receiver.recv()` blocking,
|
||||
//! `sender.send(data)` can also block when the IPC buffer is full. For this reason it is
|
||||
//! very important that all IPC receivers where we depend on non-blocking send
|
||||
//! use a router to route IPC messages to an mpsc channel. The reason why that solves
|
||||
//! the problem is that under the hood, the router uses a dedicated thread to forward
|
||||
//! messages, and:
|
||||
//!
|
||||
//! * Anything (other than a routing thread) can block on a routing thread
|
||||
//!
|
||||
//! See https://github.com/servo/servo/issues/14704
|
||||
|
||||
use backtrace::Backtrace;
|
||||
use bluetooth_traits::BluetoothRequest;
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue