I see, thank you for clarification. Can't help but note, though, that the dynamic loading case could be worked around by having a wrapper similar to the one Rust generates around calls to foreign functions, that would ensure bigger stack segment for the dynamic linker to use (only the first time a function is called). Probably not as simple as I describe this, especially if one wants to get rid of the second indirection, but possible. Had this option been considered?
On Tue, Apr 30, 2013 at 3:16 PM, Brian Anderson <[email protected]>wrote: > On 04/26/2013 04:40 PM, Vadim wrote: > > > I share your concern. It's likely that Rust tasks will never scale as >> well as Erlang and I suspect that we will ultimately want an async API that >> does not impose the expense of 1 task per I/O stream. I hope though that >> the current approach will scale 'pretty well'. >> > > Is there something inherent in Rusts segmented stacks scheme that > requires segments to be a multiple of a whole page? Could tasks be > marked for fine-grained stack allocation and extend stack one function > frame at a time? > > > Not multiples of whole pages, but stack segments must contain a 'red zone' > that does not typically execute rust code but is always available to > execute various bits of glue code, most notably the dynamic linker. When > calling a function in a dynamic library for the first time the linker will > immediately go do whatever it needs to in order to make that function > available. This requires a lot of stack. On linux it is around 1.5k, on > other platforms it is higher. All stack segments have to pay that price. >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
