| Commit message (Collapse) | Author | Age | |
|---|---|---|---|
| * | error: Consistently use Display instead of error description() | David Tolnay | 2019-03-02 |
| | | | | | | | | | | | | | | | | | The description method is deprecated and its signature forces less helpful error messages than what Display can provide. BUG=none TEST=cargo check --all-features TEST=cargo check --target aarch64-unknown-linux-gnu Change-Id: I27fc99d59d0ef457c5273dc53e4c563ef439c2c0 Reviewed-on: https://chromium-review.googlesource.com/1497735 Commit-Ready: David Tolnay <dtolnay@chromium.org> Tested-by: David Tolnay <dtolnay@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Dylan Reid <dgreid@chromium.org> | ||
| * | sync: Mutex type with methods that panic instead of return error | David Tolnay | 2018-12-05 |
| This CL adds a crate `sync` containing a type sync::Mutex which wraps the standard library Mutex and mirrors the same methods, except that they panic where the standard library would return a PoisonError. This API codifies our error handling strategy around poisoned mutexes in crosvm. - Crosvm releases are built with panic=abort so poisoning never occurs. A panic while a mutex is held (or ever) takes down the entire process. Thus we would like for code not to have to consider the possibility of poison. - We could ask developers to always write `.lock().unwrap()` on a standard library mutex. However, we would like to stigmatize the use of unwrap. It is confusing to permit unwrap but only on mutex lock results. During code review it may not always be obvious whether a particular unwrap is unwrapping a mutex lock result or a different error that should be handled in a more principled way. Developers should feel free to use sync::Mutex anywhere in crosvm that they would otherwise be using std::sync::Mutex. TEST=boot linux Change-Id: I9727b6f8fee439edb4a8d52cf19d59acf04d990f Reviewed-on: https://chromium-review.googlesource.com/1359923 Commit-Ready: David Tolnay <dtolnay@chromium.org> Tested-by: David Tolnay <dtolnay@chromium.org> Reviewed-by: Zach Reizner <zachr@chromium.org> | |||