From: Ralf Jung Date: Tue, 10 Apr 2018 12:12:28 +0000 (+0200) Subject: add link to forum; tweak intro X-Git-Url: https://git.ralfj.de/web.git/commitdiff_plain/0daac5b322a721d4ff6d5a64fb8bee48bcb37a07?ds=sidebyside;hp=c7d43e6ac3644e65e1bb445d49d3f412c87be873 add link to forum; tweak intro --- diff --git a/personal/_posts/2018-04-10-safe-intrusive-collections-with-pinning.md b/personal/_posts/2018-04-10-safe-intrusive-collections-with-pinning.md index 9ae5bd5..362a4e3 100644 --- a/personal/_posts/2018-04-10-safe-intrusive-collections-with-pinning.md +++ b/personal/_posts/2018-04-10-safe-intrusive-collections-with-pinning.md @@ -1,6 +1,7 @@ --- title: "Safe Intrusive Collections with Pinning" categories: research rust +forum: https://internals.rust-lang.org/t/safe-intrusive-collections-with-pinning/7281 --- In my [last post]({{ site.baseurl }}{% post_url 2018-04-05-a-formal-look-at-pinning %}), I talked about the new ["pinned references"](https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md) which guarantee that the data at the memory it points to will not, ever, be moved elsewhere. @@ -17,8 +18,9 @@ This part assumes some familiarity with the `Pin` API, but not with the formal m In the second part, I am going to briefly sketch a formal perspective on intrusive collections and the extended pinning guarantees. This builds on the formal notation I introduced in my last post. -Finally, I will discuss a variant of our "running example" intrusive collection that this model can *not* handle, and how the model could be extended. -This extended model will actually call for a change to the `Pin` API (or rather, for a revert to an earlier version). +Finally, I will discuss a variant of our "running example" intrusive collection that combines shared references and pinning. +It turns out this variant is actually incompatible with the formal model from the last post, but the model can be extended to fix this. +Hiwever, this extended model will actually call for a change to the `Pin` API (or rather, for a revert to an earlier version). (Btw, I'm sorry for this blog post being *even longer* than the previous. I guess I am just enjoying that there is no page limit (like there is in papers) when writing blog posts, so I can just ramble as much as I like.) @@ -461,6 +463,6 @@ I am impressed by the creativity that went into coming up with these APIs, and l The situation around shared pinning is still open, and it seems we need to have a discussion about what model we ultimately want to adopt---which code we ultimately want to be legal---and whether we want to change the `Pin` types before stabilization. Unfortunately I am four days late in my race against the [first significant user of this API](https://aturon.github.io/2018/04/06/futures2/). -Anyway, as usual, please let me know what you think! +Anyway, as usual, please [let me know what you think](https://internals.rust-lang.org/t/safe-intrusive-collections-with-pinning/7281)! #### Footnotes