Just so you know, it’s already possible to use coroutines in Swift with Venice.
https://github.com/VeniceX/Venice <https://github.com/VeniceX/Venice> > On Aug 11, 2016, at 7:36 PM, Dan Stenmark via swift-evolution > <swift-evolution@swift.org> wrote: > > 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. > > Dan > >> On Aug 11, 2016, at 3:24 PM, Goffredo Marocchi via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> LLVM is getting actual coroutine support, do you think it is going to help >> Swift started in this direction? >> >> Sent from my iPhone >> >> On 11 Aug 2016, at 22:17, Slava Pestov <spes...@apple.com >> <mailto:spes...@apple.com>> wrote: >> >>> >>>> On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> 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. >>>> >>>> Sent from my iPhone >>> >>> 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. >>> >>> Slava >>> >>>> >>>> On 11 Aug 2016, at 19:09, Kevin Ballard <ke...@sb.org >>>> <mailto:ke...@sb.org>> wrote: >>>> >>>>> 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). >>>>> >>>>> 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. >>>>> >>>>> Of course I could be wrong, but that's the impression I got after reading >>>>> a few different things about Fibers. >>>>> >>>>> -Kevin >>>>> >>>>> On Thu, Aug 11, 2016, at 10:54 AM, Goffredo Marocchi wrote: >>>>>> Hello Kevin, >>>>>> 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. >>>>>> >>>>>> On Thu, Aug 11, 2016 at 6:50 PM, Kevin Ballard <ke...@sb.org >>>>>> <mailto:ke...@sb.org>> wrote: >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> -Kevin >>>>>> >>>>>> >>>>>> On Thu, Aug 11, 2016, at 10:36 AM, Goffredo Marocchi wrote: >>>>>>> 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 :). >>>>>>> >>>>>>> On Thu, Aug 11, 2016 at 6:12 PM, Kevin Ballard via swift-evolution >>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>>> For anyone interested in reading more about Rust's decisions, here's >>>>>>> two links: >>>>>>> >>>>>>> The email about abandoning segmented stacks: >>>>>>> https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html >>>>>>> <https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html> >>>>>>> >>>>>>> The RFC to remove green threading, with motivation: >>>>>>> https://github.com/aturon/rfcs/blob/remove-runtime/active/0000-remove-runtime.md >>>>>>> >>>>>>> <https://github.com/aturon/rfcs/blob/remove-runtime/active/0000-remove-runtime.md> >>>>>>> >>>>>>> -Kevin Ballard >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 9, 2016, at 01:28 PM, Kevin Ballard 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. >>>>>>> > >>>>>>> > -Kevin Ballard >>>>>>> > >>>>>>> > On Tue, Aug 9, 2016, at 12:04 PM, Dan Stenmark via swift-evolution >>>>>>> > wrote: >>>>>>> > > 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? >>>>>>> > > >>>>>>> > > Dan >>>>>>> > > >>>>>>> > > (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.) >>>>>>> > > _______________________________________________ >>>>>>> > > 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 <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 <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 <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
