> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution > <swift-evolution@swift.org> wrote: > > The Rust language used to use a green thread model like Go (actually it > exposed a configurable threading interface so you could choose green threads > or OS threads). It also used segmented stacks like Go did. Over time, Rust > ended up dropping the segmented stacks because it significantly complicated > FFI without providing much, if any, benefit (and IIRC Go followed suite and > dropped segmented stacks somewhere around version 1.5), and then a little > while later Rust dropped green threads entirely. If you can find them, there > are lots of discussions of the pros and cons that were documented during this > process (on mailing lists, in IRC, possibly on Discourse, there's probably at > least one post about it in the Rust subreddit, etc). But ultimately, it was > determined that keeping this ability significantly complicated the Rust > runtime and it provided almost no benefit. The OS is already really good at > scheduling threads, and there's no memory savings without segmented stacks > (though the OS will map virtual pages for the stack and only allocate the > backing physical pages as the memory is touched, so even if you have a 2MB > stack, a new thread will only actually allocate something like 8kb). And > there are some pretty big downsides to green threads, such as the fact that > it significantly complicates the runtime since all I/O everywhere has to be > nonblocking and it has to be transparent to the code, and FFI ends up as a > major problem (even without segmented stacks), because you have no idea if an > FFI call will block. Green threading libraries end up having to allocate > extra OS threads just to continue servicing the green threads when the > existing threads are potentially blocked in FFI. > > So ultimately, green threads really only make sense when you control the > entire ecosystem, so you can ensure the whole stack is compatible with green > threads and won't ever issue blocking calls, and even there there's not much > benefit and there's a lot of complexity involved.
In addition to FFI, there's also no way for memory-mapped IO to be non-blocking (a page fault can only be handled by the kernel, after all). -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
