On 13-02-02 06:01 AM, Patrick Walton wrote:
> So I suppose `reserve_stack` would simply check to see whether there's
> enough stack space at runtime and turn into a no-op if there is. The
> safe interfaces to functions would always use `reserve_stack`. (We would
> enforce this with a lint pass, as earlier.) Thus, in general, if you see
> `__morestack` high in your profiles, you can fix the thrashing by simply
> adding a call to `reserve_stack` high in the call chain.
>
> This all sounds very attractive to me now.
I feel like there are (or may be) two very different topics going on
here. Can those reading fill me on whether each of these two points is
the goal?
(1) avoiding _crossings_ of rust-stack-segment-boundaries at
performance-inconvenient places.
(2) asking that a block of code run placing a chunk of code "back on
the C stack" for some sort of "stack affinity" reason (the way
certain actions have to run on particular threads at an OS level)
(3) asking that a block of code be run _uninterrupted_, regardless of
stack, in the sense of not being suspended mid-block by the
scheduler.
These all seem like .. potentially separate concerns, and potentially
all valid for different reasons. I'd like to know which we're talking about.
-Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
