On 02/05/2013 04:23 PM, Graydon Hoare wrote:
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.
This is a major motivation, at the moment particularly for SpiderMonkey
and core (though they care about this for different reasons -
SpiderMonkey cares about calls from C to Rust and core cares about the
other direction).
(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)
I'm not aware of this use case.
(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.
This isn't a motivation here and I think this use case isn't that
related to stack management and the FFI. The task has some runtime calls
used by core for this type of thing, some of which will fail dynamically
if you do the wrong thing while trying to avoid being descheduled. In
general the only time a task will be descheduled is when using pipes or
other synchronization code. This could change if we ever put yields on
loop edges, etc. but I'm not sure we want to. If somebody does want to
run without interference from the scheduler then they could do it in a
raw thread.
Aside from the aforementioned performance considerations, my major
concern is that our stack management model is more complex than it
should be (with the distinction between stack growth and stack
switching), and the way we manage stacks is reflected in the FFI.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
