> On Aug 9, 2016, at 1:59 PM, Joe Groff via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> 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).
Even buffered file I/O via read(2) and write(2) is blocking on most *nix platforms. AFAIK there's some work being done on non-blocking buffered reads on Linux, but it appears to be a completely new API distinct from the existing epoll for sockets or aio_* for direct file I/O, and of course Darwin doesn't have an equivalent. Slava > > -Joe > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
