On Fri, Jul 5, 2013 at 11:07 PM, Daniel Micay <[email protected]> wrote:
> On Fri, Jul 5, 2013 at 4:58 PM, Bill Myers <[email protected]> wrote: > > I believe that instead of segmented stacks, the runtime should determine > a > > tight upper bound for stack space for the a task's function, and only > > allocate a fixed stack of that size, falling back to a large "C-sized" > stack > > if a bound cannot be determined. > > > > Such a bound can always be computed if there is no recursion, dynamic > > dispatch, dynamic allocation on the stack, or foreign C functions. > > > > In practice this means everything would use a large stack. It misses > the use case of scaling up tasks to many I/O requests by trading off > performance for small size. > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > There was, at one point, a discussion on providing a #[reserve_stack(2048)] attribute for extern functions where the developer would indicate to the runtime that said function would never need more than N bytes of stack. It was deemed burdensome, and might be somewhat, however I still believe that annotating some key C extern functions (such as those performing IO) would allow computing this upper-bound in more cases. Of course, the real experiment would be to instrument the compiler and see exactly how many tasks can indeed be so bounded... and *why* the others cannot; unfortunately it might take some time to get it working. -- Matthieu
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
