Hi Brian, Can you please elaborate on why segmented stacks fell out of favor? Maybe it's been discussed among the core Rust team, but external people like me are probably wondering why. It seems to me that segmented stacks would be essential for async I/O and actor-based architectures, no?
Vadim On Mon, Oct 21, 2013 at 3:05 PM, Brian Anderson <bander...@mozilla.com>wrote: > On 10/21/2013 07:30 AM, Corey Richardson wrote: > >> I've written a blog post about stack safety and a proposal for how I >> think it should be implemented in Rust: >> http://cmr.github.io/blog/**2013/10/21/on-stack-safety/<http://cmr.github.io/blog/2013/10/21/on-stack-safety/> >> >> Thoughts, comments? I'm going to implement this after my (ill-kept) >> hiatus if there's consensus that this is a good idea. >> > > Thanks for writing this up! > > I agree with Patrick that static analysis isn't worth trying. > > As to the dynamic checks, I'd suggest just throwing out segmented stacks. > Let's decide once and for all that they're a losing proposition; the tide > seems to have turned against them. At that point the choice for checking > stack overflow is between guard pages and the __morestack prologue, but why > offer both options? Let's just pick one and keep it simple. > > The prospect of disabling stack safety on a crate level is interesting, > but it's not clear to me what the use case is for combining unsafe crates > with safe crates. The only reason I see for wanting to turn off the stack > checks is for embedded cases that don't want to use tasks and don't want to > link to morestack.a (assuming we use __morestack for the check). I'd like > to know more about the reasoning here. > > The harder problem, not addressed here, is what to do when we run out of > stack. For various reasons recovering in this situation is very hard, and > right now the best we can do is abort. > > So my opinion of what to do with stacks is different: > > * Keep aborting when running out of stack via __morestack (we're already > doing this) > * Start using mmapping to map pages of stack on demand (this happens > automatically on some linux configurations but needs to be done explicitly > to guarantee lazy allocation). > * Consider switching to guard pages for the stack check - this has some > downsides in that the point of failure is arbitrary (not in the fn > prologue) so much harder to recover from. Can we commit to making stack > overflow a process abort? > > If we use guard pages for the check then there's not even any code gen > difference between stack-safe Rust and stack-unsafe Rust; it's just a > matter of runtime setup. > > ______________________________**_________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
