clarify a bit the I/O story

[web.git] / personal / _posts / 2018-07-13-arc-synchronization.md

diff --git a/personal/_posts/2018-07-13-arc-synchronization.md b/personal/_posts/2018-07-13-arc-synchronization.md
index 1ad8a4695fc2502ecdb75852aa879916dc5525be..2e8f7eab1d2510c2cb57d68a308552dccfdc920f 100644 (file)
--- a/personal/_posts/2018-07-13-arc-synchronization.md
+++ b/personal/_posts/2018-07-13-arc-synchronization.md
@@ -188,3 +188,5 @@ In that paper, we did not (yet) have the tools to reason realistically about the
 This is one of the simplifications we made compared to real Rust to make the verification feasible.
 We were realistic enough to find [another bug]({{ site.baseurl }}{% post_url 2017-06-09-mutexguard-sync %}), but not realistic enough for this one.
 Hai and Jacques-Henri are currently working on remedying this particular simplification by extending the first RustBelt paper to also cover weak memory, and that's when they ran into this problem.
 This is one of the simplifications we made compared to real Rust to make the verification feasible.
 We were realistic enough to find [another bug]({{ site.baseurl }}{% post_url 2017-06-09-mutexguard-sync %}), but not realistic enough for this one.
 Hai and Jacques-Henri are currently working on remedying this particular simplification by extending the first RustBelt paper to also cover weak memory, and that's when they ran into this problem.

+
+**Update:** Turns out Servo has a [copy of `Arc`](https://doc.servo.org/servo_arc/index.html) that [has the same problem](https://github.com/servo/servo/issues/21186). So we got two bugs for the price of one. :)  **/Update**