On 11/04/2013 07:50 PM, Bill Myers wrote:
The advantage of segmented stacks is that blocked tasks only take up
as much memory as they actually need to store state, so that for
instance a network server can use a task for each connection, and
still only use, say, 64 bytes per connection if that's possible
instead of the number of stack pages that got allocated for previous
computation (assuming an "extreme" version that allocates a stack
segment on every call).
In practice there are a number of other limitations that would ever
prevent Rust from reducing a stack segment to 64 bytes. Rust segmented
stacks still needed a large 'red zone' for running various bits of code,
the most problematic being the dynamic linker. On Linux the dynamic
linker needs about 2k of space to resolve symbols, on Mac much more.
There are ways to work around this by writing our own dynamic linker or
disallowing it, but there are significant obstacles to making the stack
as small as one might want. We had the Linux minimum stack down to ~3k
(1k for Rust code + *2k* red zone). With mmapped stacks we are always
free to unmap pages that aren't in use, saving space.
However, there is another approach that can replace segmented stacks
for that purpose, namely having the compiler automatically transform
blocking functions to instead return a future (with limited lifetime).
This means that segmented allocation only happens for functions that
indirectly perform I/O and only allocates the exact amount of memory
needed to retain state that must persistent across the blocking I/O
operation, while other functions execute normally using traditional
stacks.
The simplest example of this feature is async/await in C# 5, and Scala
has a delimited continuation passing transformation that can be used
to do the same thing.
Has this been considered for Rust?
Aren't these futures fullfilled by some kind of task abstraction that
runs on a thread pool or something? Do these tasks not have their own
stacks? I have thought about C#'s async/await feature but decided it was
more or less equivalent to tasks.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
