<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Guys, as I have already mentioned a couple of times in this thread, let’s please not turn this into a explicit discussion about how Swift could do concurrency. That discussion is at least a few more months out, especially with memory ownership ala Rust/Cyclone being explored for Swift 4. I intended this thread to be about general language & runtime design theory above all else, and I’m sure the team is already quite weary of folks jumping the gun and posting their pitches.</div><div class=""><br class=""></div><div class="">Dan</div><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 11, 2016, at 3:24 PM, Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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=""><div style="direction: inherit;" class="">LLVM is getting actual coroutine support, do you think it is going to help Swift started in this direction?</div><br class="">Sent from my iPhone</div><div class=""><br class="">On 11 Aug 2016, at 22:17, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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=""><div style="direction: inherit;" class="">Thanks for the concise and clear review of green threads :). I can understand the concerns of runtime implementation when the runtime of the language is replacing the kernel scheduler.</div><br class="">Sent from my iPhone</div></div></div></blockquote><div class=""><br class=""></div><div class="">One interesting thing that you can do to get around the limitations is to run blocking system calls in their own special thread pool off to the side. This is how node.js deals with blocking I/O I believe. However this seems like it would add a lot of overhead, and it’s probably not a direction we want to go in with Swift. Of course nothing prevents users from developing their own thread pool libraries, if they so choose. Even coroutines would not be too difficult to do with Swift, since we don’t do anything funny with the callstack. So the usual tricks should work.</div><div class=""><br class=""></div><div class="">Slava</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class="">On 11 Aug 2016, at 19:09, Kevin Ballard <<a href="mailto:kevin@sb.org" class="">kevin@sb.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">
<title class=""></title>
<div class="">AIUI, fibers are basically coroutines. Even the Naughty Dog presentation says that fibers are run on threads, and you have to make an explicit call to switch between fibers. Looking at Ruby's Fiber type, that's also an explicit coroutine, where you actually yield up a value when you yield your fiber (which is exactly what coroutines do).<br class=""></div>
<div class=""><br class=""></div>
<div class="">So basically, green threading is preemptive multithreading where the preempting is done in user-space by the runtime (so it only happens at specific points where your code calls back into the runtime, but it can happen at any of those points), and multiple green threads get scheduled onto the same OS thread, whereas fibers is cooperative multithreading where your code explicitly yields back to the runtime to switch fibers.<br class=""></div>
<div class=""><br class=""></div>
<div class="">Of course I could be wrong, but that's the impression I got after reading a few different things about Fibers.</div>
<div class=""><br class=""></div>
<div class="">-Kevin</div>
<div class=""><br class=""></div>
<div class="">On Thu, Aug 11, 2016, at 10:54 AM, Goffredo Marocchi wrote:<br class=""></div>
<blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><div class="">Hello Kevin,<br class=""></div>
</div>
<div class="">I may be wrong in my equating support for fibers to green threads (and the runtime cost of supporting them), but I do have seen and linked to a presentation of the use and more than trivial benefits to Naughty Dog's engine in utilising the 8 Jaguar x86 cores in the PlayStation 4 CPU. Although like you said, it did not come for free or without evident pain points for them.<br class=""></div>
</div>
<div class=""><div class=""><br class=""></div>
<div defang_data-gmailquote="yes" class=""><div class="">On Thu, Aug 11, 2016 at 6:50 PM, Kevin Ballard <span dir="ltr" class=""><<a href="mailto:kevin@sb.org" class="">kevin@sb.org</a>></span> wrote:<br class=""></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;" defang_data-gmailquote="yes" class=""><div class=""><u class=""></u><br class=""></div>
<div class=""><div class="">I'm confused by your email. Rust is all about performance, and embedded devices are one of the targets for Rust. And I can't think of any language that uses green threading that is appropriate for constrained devices (e.g. Go definitely isn't appropriate for that). One of the arguments for getting rid of green threading in Rust is that the extra runtime complexity imposed a performance cost.<span class=""><span class="colour" style="color:rgb(136, 136, 136)"></span></span><br class=""></div>
<div class=""><span class=""><span class="colour" style="color:rgb(136, 136, 136)"></span></span><br class=""></div>
<div class=""><span class=""><span class="colour" style="color:rgb(136, 136, 136)"></span></span><br class=""></div>
<div class=""><span class=""><span class="colour" style="color:rgb(136, 136, 136)">-Kevin</span></span><br class=""></div>
<div class=""><span class=""><span class="colour" style="color:rgb(136, 136, 136)"></span></span><br class=""></div>
<div class=""><div class=""><div class=""><br class=""></div>
<div class="">On Thu, Aug 11, 2016, at 10:36 AM, Goffredo Marocchi wrote:<br class=""></div>
<blockquote type="cite" class=""><div dir="ltr" class="">Thanks Kevin, I think they have accepted that they do not need to enter every segment of computing so the extra performance they could get on some devices is not worth the risk and the complexity it brings. Not everyone is trying to cram complex 3D experiences at 60-90+ FPS on a console like constrained devices and I guess Rust is not targeting that right now :).<br class=""></div>
<div class=""><div class=""><br class=""></div>
<div class=""><div class="">On Thu, Aug 11, 2016 at 6:12 PM, Kevin Ballard via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;" class=""><div class="">For anyone interested in reading more about Rust's decisions, here's two links:<br class=""></div>
<div class=""><br class=""></div>
<div class="">The email about abandoning segmented stacks: <a href="https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html" class="">https://mail.mozilla.org/piper<wbr class="">mail/rust-dev/2013-November/<wbr class="">006314.html</a><br class=""></div>
<div class=""><br class=""></div>
<div class="">The RFC to remove green threading, with motivation: <a href="https://github.com/aturon/rfcs/blob/remove-runtime/active/0000-remove-runtime.md" class="">https://github.com/aturon/rfcs<wbr class="">/blob/remove-runtime/active/<wbr class="">0000-remove-runtime.md</a><br class=""></div>
<div class=""><br class=""></div>
<div class="">-Kevin Ballard<br class=""></div>
<div class=""><br class=""></div>
<div class=""><div class=""><div class=""><br class=""></div>
<div class="">On Tue, Aug 9, 2016, at 01:28 PM, Kevin Ballard wrote:<br class=""></div>
<div 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.<br class=""></div>
<div class="">><br class=""></div>
<div 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.<br class=""></div>
<div class="">><br class=""></div>
<div class="">> -Kevin Ballard<br class=""></div>
<div class="">><br class=""></div>
<div class="">> On Tue, Aug 9, 2016, at 12:04 PM, Dan Stenmark via swift-evolution wrote:<br class=""></div>
<div class="">> > I'd like to inquire as to what the Swift team thoughts on Go's concurrency model are? I'm not referring to convenience of the 'go' keyword and nor am I referring to how the language handles Channels, both of which being what most folks associate with it. Rather, I'd like to ask about the language's use of Green Threads and how the runtime handles the heavy lifting of multiplexing and scheduling them. What are some of the strengths and weaknesses the Swift team sees to Go's approach?<br class=""></div>
<div class="">> ><br class=""></div>
<div class="">> > Dan<br class=""></div>
<div class="">> ><br class=""></div>
<div class="">> > (DISCLAIMER: I'm posting this for academic reasons, not as a pitch. While the Swift team's responses may inform opinions on the matter, I do not want this to turn into a 'this is how I think Swift should do concurrency' debate. That discussion will come when it comes.)<br class=""></div>
<div class="">> > ______________________________<wbr class="">_________________<br class=""></div>
<div class="">> > swift-evolution mailing list<br class=""></div>
<div class="">> > <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""></div>
<div class="">> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class=""></div>
<div class="">______________________________<wbr class="">_________________<br class=""></div>
<div class="">swift-evolution mailing list<br class=""></div>
<div class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class=""></div>
</div>
</div>
</blockquote></div>
</div>
</blockquote><div class=""><br class=""></div>
</div>
</div>
</div>
</blockquote></div>
</div>
</blockquote><div class=""><br class=""></div>
</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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><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=""></body></html>