On Tue, Oct 29, 2013 at 7:08 AM, Niko Matsakis <n...@alum.mit.edu> wrote:

> If I understand correctly, what you are proposing is to offer fixed
> size stacks and to use a guard page to check for stack overflow (vs a
> stack preamble)?
>
> My two thoughts are:
>
> 1. I do think segmented stacks offer several tangible benefits:
>
> - Recursion limited only by available memory / address space
> - Avoid chewing up address space on 32 bit builds
>
> However, I can accept that on balance they are not worth the price,
> given that point #2 is probably not that important for 64-bit systems.
>
> It is sad to lose limitless recursion but typically one can rewrite
> routines that recurse arbitrarily deep to use a stack on the heap,
> though sometimes the code is very unnatural, and using a stack on the
> heap will not play as well with lifetimes, since the compiler doesn't
> know that you are obeying a stack discipline.
>
> 2. I think that our official semantics for stack overflow should be
> task failure, not abort. There are some technical challenges to be
> overcome with regard to the best way to signal/detect stack overflow,
> and I'm fine with this being a "todo" item (possibly for a long time).
> But abort is wrong.
>
> One non-technical difficulty to failing on overflow is how to handle
> user-defined destructors when there is no stack to run them on -- but
> I think this is adequately addressed by keeping a red zone (so that
> simple dtors work) and implementing Graydon's plan for handling
> recursive failure otherwise. We also have to modify drop glue to not
> be recursive (see point #1 about the convenience of limitless
> recursion -- though of course drop glue must be ready for OOM as
> well).
>

If we want to unwind on task failure, we'll need to disable the `prune-eh`
pass that bubbles up `nounwind` since every function will be able to
unwind. I think it will cause a very significant increase in code size.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to