Hello, Segmented stacks were ditched because of performance issues that were never fully resolved, especially when every opaque call (C, ...) required allocated a large stack up-front.
Still, there are platforms (FreeBSD) with small stacks where the idea of segmented tasks could ease development... so what if we let the developer ship in ? The idea of semi-automated segmented stacks would be: - to expose to the user how many bytes worth of stack are remaining - to let the user trigger a stack switch This system should keep the penalty close to null for those who do not care, and be relatively orthogonal to the rest of the implementation: - how many bytes remaining carries little to no penalty: just a pointed substraction between the current stack pointer and the "end-of-stack" pointer (which can be set once and for all at thread start-up) - the stack switch is voluntary, and can include a prelude on the new stack that automatically comes back to its parent so that most code should not care, no penalty in regular execution (without it) - I foresee some potential implementation difficulty for the unwinder, did it ever work on segmented stacks ? Was it difficult/slow ? Does performance of unwind matter that much ? Work-around: In the absence of segmented stacks, the user can only resolve to using another task to get a "free" stack. Unfortunately, because of the (great!) memory safety of Rust this other task cannot readily access its parent task's memory. I do not remember whether this idea was investigated when segmented tasks were removed. I thought it might be interesting to consider, although... it is probably useless for 1.0 anyway. -- Matthieu
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
