On Thu, Nov 14, 2013 at 7:31 PM, Nathan Myers <n...@cantrip.org> wrote: > On 11/11/2013 03:52 PM, Gaetan wrote: >> >> Can we have Two rust? >> >> The first one would be easy to learn, easy to read, and do most of ones >> would expect: on demand garbage collector, traits, Owned pointers,... > >> >> >> The second one would include all advanced feature we actually don t >> need everyday > > > This is a special case of the general design principle: push policy > choices up, implementation details down. > > There's no need to choose between M:N vs. 1:1 threading, or contiguous > vs. segmented stacks, at the language design level. It just takes > different kinds of spawn(). The default chosen is whatever works most > transparently. Similarly, a thread with a tiny or segmented stack is > not what we usually want, but when we (as users) determine we can live > with its limitations and costs -- including expensive call/return > across segment boundaries, and special ffi protocol -- there's no > fundamental reason not to support it.
In many cases, there is a need to choose between supporting one or the other, or having sub-par support for both. If segmented stacks are supported, there will be preludes in nearly every single function to check the available stack space and there is the need to carefully annotate all the foreign function calls. Go always uses segmented stacks, and therefore it reimplements the support offered by the C standard library to avoid stack switches. It even uses a special calling convention to make context switches cheap (on a modern Intel CPU only 3 registers to swap, instead of 16 general purpose ones + float state + 32 AVX registers + segment registers and more). The same is true for 1:1 vs. M:N threading. If a task doesn't map 1:1 to a thread ID and thread-local data, support for C libraries using thread-local data will always be stuck with an inferior API to C/C++. There's also the inability to directly use static thread-local data which is very fast and easy to use. > There are practical reasons, though. Each choice offered adds to the > complexity of the implementation, and multiplies the testing needed. > We don't want it to be very expensive to port the rust runtime to a > new platform, so these special modes should be limited in number, and > optional. Ideally a program could try to use one and, when it fails, > fall back to the default mode. There is no need to make this falling- > back invisible, but there are good reasons not to. An example of this is that Rust's standard library currently assumes every CPU has the baseline set of registers of the architecture, and doesn't swap the others. For an example of the consequences, Rust doesn't support using AVX on x86_64 and or SSE/AVX on x86. It would be incredibly complex to support every variation of various architectures via runtime selection of the context switching code. The reason for Rust not simply supporting (almost) every architecture that LLVM supports out-of-the-box is M:N threading. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
