Am 02.02.2013 10:16, schrieb Patrick Walton:
On 2/1/13 11:02 PM, Brian Anderson wrote:
In the library we add this sort of function that simply guarantee that
the closure has some amount of stack available.
do reserve_stack(Standard) { rust_task_fail(); }
do reserve_stack(Tiny) {... }
do reserve_stack(Large) { }
do reserve_stack(Size(4096)) { }
My main worry about this is that it's always guesswork. Determining
how much stack a C function needs is really hard and involves doing a
lot of non-local reasoning. Getting it wrong can result in exploitable
security vulnerabilities. From a safety POV, it seems that you always
really want as big a stack as possible, unless the function is
something trivial like floor().
Ultimately we never often want a stack to be increased in size as this
seems to be a quite expensive operation. Calling a function that crosses
stack space
boundaries (i.e. when it has to alloc new stack space) inside a loop
might severly affect performance. "do reserve_stack" could be used to
prevent that, but
the programmer need to be aware of that. At least theoretical it should
be possible to calculate how much stack space a given function needs
including
all the space that all called functions need. Recursive functions would
result in "unlimited stack space", just because we cannot analyse the
depths of
the calls. But for most of the code, we would know the maximum stack
space used. We could use this when we start new tasks to allocate a
contiguous
stack large enough to hold the whole computation of that task without
the need to resize (in which case we could optimize away the checks in front
of each function).
Most functions called by FFI should have a pretty flat call hierarchy.
At least functions in lib_c do have. Ideally there is information at
link time how much
space a given function consumes (I read something about this topic on
LLVM segmented stacks). If not, then it is always a guess and it might
be better
to perform those calls only inside a special task and make sure this
task has enough space and that it is protected against stack overflowing
(don't have
native threads a guard page after the stack segment?).
Michael
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
