On Thu, Jul 4, 2013 at 5:33 PM, Patrick Walton <[email protected]> wrote: > 1. There is no way for the compiler or runtime to know ahead of time how > much stack any given task will need, because this is based on dynamic > control flow.
There is, unfortunately, no easy way for the user to know ahead of time either. On embedded systems, the traditional way to figure this out has been to use a "watermark" - fill the stack space with a pattern, then scan it later to see how much was overwritten (there is no MMU, so no way to grow the stack, and often times a stack overflow is undetectable unless it starts corrupting other memory). In a lot of things, the startup time of growing a stack is undesirable, even when debugging. Maybe an equivalent "watermark" in Rust could be implemented, using the existing stack growing routines, but having a very large stack preallocated at first, so that the user could go back later and fine tune the stack sizes. > 4. The benefit above is significantly reduced when calling into C code, and > all solutions to this either hurt the benefit more or significantly penalize > the FFI. > Calling C code is really unfortunate, and would break the watermarking idea above. Maybe one option would be to specially compile C code with the extra stack size instrumentation in place. This wouldn't really work on the desktop with shared libraries, though. > I think that segmented stacks just don't work. *Relocatable* stacks may > work, but not in Rust. From what I have read, Walter Bright and Rob Pike > agree. > > At this point I'd like to suggest just allowing the user to choose a stack > size on a per-task basis, and failing if the stack size is exceeded. > Basically `__morestack` would turn into `fail`. > > Brian has pointed out to me that, currently, running out of stack has to > abort the whole process, because the DWARF unwinder doesn't consider > `__morestack` a "may-throw" position and as a result the arguments would > leak. There are a number of ways we could fix this, ranging from principled > to hacky. But for now I think aborting on stack exhaustion wouldn't be the > end of the world (although others may disagree). It's far better than weird unrelated bugs showing up due to memory corruption, as is usually the case on embedded. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
