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.
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 < >> email@example.com> wrote:
For anyone interested in reading more about Rust's decisions, here's two
The email about abandoning segmented stacks:
The RFC to remove green threading, with motivation:
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
> > firstname.lastname@example.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
swift-evolution mailing list