<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">According to&nbsp;<a href="http://c9x.me/art/gthreads/intro.html" class="">http://c9x.me/art/gthreads/intro.html</a>&nbsp;I would guess so - pretty much userland threads - swapping context without kernel.<div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 9, 2016, at 11:07 PM, Goffredo Marocchi via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Talking about green threads, are they similar to fibers?&nbsp;<a href="http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine" class="">http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine</a><br class=""><br class="">Sent from my iPhone</div><div class=""><br class="">On 9 Aug 2016, at 21:59, Joe Groff via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">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.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">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.</span><br class=""></blockquote><span class=""></span><br class=""><span class="">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).</span><br class=""><span class=""></span><br class=""><span class="">-Joe</span><br class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>