Re: [swift-evolution] [Swift 4.0] Conditional conformances via protocol extensions

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Aug 4, 2016, at 2:36 AM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>>> On 4 Aug 2016, at 03:19, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> On Aug 3, 2016, at 10:17 AM, Manav Gabhawala via swift-evolution 
>>>  wrote:
>>> 
>>> I was wondering why this would put any more of a burden on the runtime
>>> than simple inheritance of protocols. The way this could be
>>> implemented is to augment the ConformanceTable for nominal types by
>>> looking up its protocol extension’s inheritance clauses. I can
>>> definitely see this impacting compile time but I don’t see why runtime
>>> performance will be any different than simple inheritance. Further,
>>> cyclic chains can be detected and broken (compiler error) during the
>>> second pass of semantic analysis.
>> 
>> My understanding—which may be incorrect, by the way—is that the issue is 
>> mainly with protocol extensions adding conformances, not specifically with 
>> those conformances being conditional, and that it specifically has to do 
>> with `is` and `as?` checks across module boundaries.
>> 
>> Suppose you have these declarations in module M:
>> 
>>public protocol AProtocol {…}
>>public protocol BProtocol: AProtocol {…}
>>public protocol CProtocol {…}
>>
>>// Public or otherwise doesn't matter here.
>>public struct Foo: BProtocol {…}
>> 
>> Foo essentially has a flat list of the protocols it conforms to attached to 
>> it. Notionally, you can think of that list as looking like:
>> 
>>Foo.self.conformsTo = [BProtocol.self, AProtocol.self]
>> 
>> And when you write `foo is CProtocol`, that eventually translates into:
>> 
>>foo.dynamicType.conformsTo.contains(CProtocol.self)
>> 
>> For a `Foo`, since the `conformsTo` list doesn't include `CProtocol.self`, 
>> it returns `false`.
>> 
>> Now imagine that you write a new module, N, and in it you say:
>> 
>>extension Foo: CProtocol {…}
>> 
>> You have now retroactively conformed `Foo` to `CProtocol`. Swift needs to 
>> reach into module M and add `CProtocol.self` to the `Foo.self.conformsTo` 
>> list. This is perfectly doable for a concrete type—it's one flat list, after 
>> all.
>> 
>> Instead, though, imagine that module N extended `AProtocol` to add a 
>> conformance:
>> 
>>extension AProtocol: CProtocol {…}
>> 
>> There are two ways to handle this. One is to find all types conforming to 
>> `AProtocol`, recursively, and add `CProtocol.self` to their conformance 
>> list. The other is to scrap the flat list of conformances and instead make 
>> `is` and `as?` recursively search each protocol. Either way, you have 
>> replaced a fast, flat operation with a slow, recursive one.
>> 
>> Conditional conformance adds another wrinkle to this, of course—you must not 
>> only recursively search the list, but also evaluate the condition to see if 
>> it applies in this case. But the general problem of having to replace a fast 
>> search with a slow search applies either way.
> 
> Great explanation! This switch from flat to recursively searched though seems 
> like it would only occur when the extension is in an external module though; 
> for internal modules would it not still be possible to determine the flat 
> list for each type? In that case extending a type from another module could 
> be either disallowed, or produce a warning to indicate the performance 
> implication?
> 
> The feature would still be very useful even just for internal use after all. 
> Also it seems useful on a relatively small number of types, and the number of 
> external modules that need/want to do this must narrow that even further, so 
> external extensions may be quite niche, i.e- not worth losing the feature for 
> internal use if that is indeed easier?

Swift doesn't really have any features that stop working across modules. We're 
okay with the programmer having to think more and be more explicit across 
module boundaries (since it is API design at that point), but it'd take a very 
strong argument to have different runtime semantics across module boundaries. 

FWIW, I'm planning to write a complete proposal for conditional conformances 
and will start posting drafts once it is far enough along to be useful. It 
won't have support for protocols conforming to other protocols, though. 

  - Doug

> ___
> 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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0137: Avoiding Lock-In to Legacy Protocol Designs

[Brent Royal-Gordon via swift-evolution]

> On Aug 10, 2016, at 2:03 PM, John McCall  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0137: Avoiding Lock-In to Legacy Protocol Designs" begins 
> now and runs through August 14. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0137-avoiding-lock-in.md

'ExpressibleByStringInterpolation' is deprecated: it will be replaced 
or redesigned in Swift 4.0.  Instead of conforming to 
'ExpressibleByStringInterpolation', consider adding an 'init(_:String)'

I'm not sure I understand this error message. What is the second sentence 
trying to imply you should do instead of conforming?

Otherwise, +1 to all of this.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ABI in Layman's terms?

[Brent Royal-Gordon via swift-evolution]

> On Aug 11, 2016, at 1:57 PM, Slava Pestov via swift-evolution 
>  wrote:
>> Here's a document outlining what will be ABI compatible and what will not -- 
>> keep in mind that a good chunk of this is not yet implemented:
>> 
>> https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst
> 
> As a follow-up explanation, when we talk about the ABI, we're really talking 
> about three orthogonal "axes" along which we would like to "move" without 
> breaking compatibility with existing binaries:
> 
> - The first axis is the machine-level calling conventions and memory layout. 
> For example, what registers to pass function arguments and returns in, the 
> rules for alignment and padding of fields in an aggregate type, which entry 
> points the Swift runtime exports and what their behavior should be. Once we 
> commit to a stable ABI along this axis, you will get interoperability between 
> *compiler versions* -- the same exact library built with one version of the 
> compiler will remain compatible with clients after being recompiled with 
> another version, because their conventions will match up. Note that this does 
> not help you if the library itself changes in any way.
> 
> - The second axis is the resilience work I called out in my previous e-mail. 
> Here, we're trying to define language features and implementation techniques 
> that allow a library to evolve in a forward-compatible manner, as long as the 
> developer follows certain guidelines. Here, the goal is if you should be able 
> to compile your library, make some changes to add new APIs, and recompile it 
> *with the same compiler*, without breaking downstream clients, as long as you 
> follow the library evolution guidelines (Also, you can imagine one day having 
> an 'ABI diff' tool to automate this).
> 
> - The third axis is the standard library itself. Stability of runtime 
> interfaces and the extra indirection to enable resilience is all great, but 
> it won't help you as long as the standard library API is evolving in a 
> non-backwards compatible manner -- for example, if we remove a method on 
> String. So once the other two areas have been addressed, the last thing to 
> lock down is the standard library interface itself.

I think perhaps the other thing that might matter here is that we can always 
add to the ABI in backwards-compatible ways. So, for instance, we don't have to 
nail down all generics features immediately just because they affect the ABI; 
we just need to nail down the ABIs of existing features, plus any new features 
which will change the design of existing standard library features. If we ever 
add, say, higher-kinded types, they will certainly have some kind of 
representation in the ABI, but as long as they don't affect the binary 
representation of non-higher-kinded types, that won't really affect 
compatibility with existing code.

Similarly, there's a straightforward way to implement COWed structs in a 
backwards compatible way: treat them as a struct wrapping a reference to an 
object containing the data. As long as the compiler implements COWed structs in 
that fashion, or in any other way that's expressible in the existing ABI, COW 
structs are only an issue if we redesign inlineable parts of the standard 
library to use them.

(Correct me if I'm wrong, because I might be, but that's the impression I have.)

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Dan Stenmark via swift-evolution]

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 
>  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  > wrote:
> 
>> 
>>> On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution 
>>> > 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 >> > 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  > 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 
>> > 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 
>> 
>> 

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Goffredo Marocchi via swift-evolution]

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  wrote:
> 
> 
>> On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution 
>>  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  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  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 
>  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
> 
> The RFC to remove green threading, with motivation: 
> https://github.com/aturon/rfcs/blob/remove-runtime/active/-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 

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Slava Pestov via swift-evolution]

> On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution 
>  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 > 
> 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 >> > 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 
 > 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 
 
 
 The RFC to remove green threading, with motivation: 
 https://github.com/aturon/rfcs/blob/remove-runtime/active/-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, 

Re: [swift-evolution] ABI in Layman's terms?

[Slava Pestov via swift-evolution]

> On Aug 11, 2016, at 1:48 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
>> 
>> On Aug 11, 2016, at 4:27 AM, David Hart via swift-evolution 
>> > wrote:
>> 
>> I'd also like to understand this more and this answer does not completely 
>> satisfy me. I understand backwards compatibility, especially in terms of 
>> source breaking changes.
>> 
>> I have more difficulties understanding what breaks or not the ABI and how to 
>> make educated guesses about what features will require breaking it
> 
> This is hard to explain right now without detailed knowledge of IRGen and 
> SILGen internals. However we are planning on relaxing the restrictions as 
> much as possible, so that source-compatible changes remain binary compatible. 
> For example, we would like to be able to add new fields to structs, change 
> computed properties to stored and vice versa, insert new classes in a 
> hierarchy, add cases to enums, and so on. This falls under the umbrella of 
> "resilience".
> 
> Here's a document outlining what will be ABI compatible and what will not -- 
> keep in mind that a good chunk of this is not yet implemented:
> 
> https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst 
> 
As a follow-up explanation, when we talk about the ABI, we're really talking 
about three orthogonal "axes" along which we would like to "move" without 
breaking compatibility with existing binaries:

- The first axis is the machine-level calling conventions and memory layout. 
For example, what registers to pass function arguments and returns in, the 
rules for alignment and padding of fields in an aggregate type, which entry 
points the Swift runtime exports and what their behavior should be. Once we 
commit to a stable ABI along this axis, you will get interoperability between 
*compiler versions* -- the same exact library built with one version of the 
compiler will remain compatible with clients after being recompiled with 
another version, because their conventions will match up. Note that this does 
not help you if the library itself changes in any way.

- The second axis is the resilience work I called out in my previous e-mail. 
Here, we're trying to define language features and implementation techniques 
that allow a library to evolve in a forward-compatible manner, as long as the 
developer follows certain guidelines. Here, the goal is if you should be able 
to compile your library, make some changes to add new APIs, and recompile it 
*with the same compiler*, without breaking downstream clients, as long as you 
follow the library evolution guidelines (Also, you can imagine one day having 
an 'ABI diff' tool to automate this).

- The third axis is the standard library itself. Stability of runtime 
interfaces and the extra indirection to enable resilience is all great, but it 
won't help you as long as the standard library API is evolving in a 
non-backwards compatible manner -- for example, if we remove a method on 
String. So once the other two areas have been addressed, the last thing to lock 
down is the standard library interface itself.

> 
>> 
>> On 11 Aug 2016, at 13:24, Anton Zhilin via swift-evolution 
>> > wrote:
>> 
>>> 2016-08-11 11:52 GMT+03:00 Jonathan Hull via swift-evolution 
>>> >:
>>> Could someone explain in simple terms what the ABI is and what sorts of 
>>> things might affect it?
>>> 
>>> I had thought it was the layout in memory of structs/classes/etc… and how 
>>> the program knows where to go to find a particular field.  This seems to be 
>>> incorrect though, as I have seen many features that I would assume have 
>>> some affect on this layout ruled “out of scope for phase 1”.  For example, 
>>> I would think that many generics features would have an impact on the ABI, 
>>> or the idea of COW (via secret boxing) for structs, or even union types.
>>> 
>>> At the very least, I would think that mix-ins would have a fairly 
>>> significant effect.
>>> 
>>> ABI stability means that changes will have to be backwards compatible after 
>>> a certain stage. If we can add mixins feature without modifying old code 
>>> (and its SIL and IR and whatever), then we are fine. 
>>> ___
>>> 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
> 
> ___
> swift-evolution 

Re: [swift-evolution] ABI in Layman's terms?

[Slava Pestov via swift-evolution]

> On Aug 11, 2016, at 4:27 AM, David Hart via swift-evolution 
>  wrote:
> 
> I'd also like to understand this more and this answer does not completely 
> satisfy me. I understand backwards compatibility, especially in terms of 
> source breaking changes.
> 
> I have more difficulties understanding what breaks or not the ABI and how to 
> make educated guesses about what features will require breaking it

This is hard to explain right now without detailed knowledge of IRGen and 
SILGen internals. However we are planning on relaxing the restrictions as much 
as possible, so that source-compatible changes remain binary compatible. For 
example, we would like to be able to add new fields to structs, change computed 
properties to stored and vice versa, insert new classes in a hierarchy, add 
cases to enums, and so on. This falls under the umbrella of "resilience".

Here's a document outlining what will be ABI compatible and what will not -- 
keep in mind that a good chunk of this is not yet implemented:

https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst

> 
> On 11 Aug 2016, at 13:24, Anton Zhilin via swift-evolution 
> > wrote:
> 
>> 2016-08-11 11:52 GMT+03:00 Jonathan Hull via swift-evolution 
>> >:
>> Could someone explain in simple terms what the ABI is and what sorts of 
>> things might affect it?
>> 
>> I had thought it was the layout in memory of structs/classes/etc… and how 
>> the program knows where to go to find a particular field.  This seems to be 
>> incorrect though, as I have seen many features that I would assume have some 
>> affect on this layout ruled “out of scope for phase 1”.  For example, I 
>> would think that many generics features would have an impact on the ABI, or 
>> the idea of COW (via secret boxing) for structs, or even union types.
>> 
>> At the very least, I would think that mix-ins would have a fairly 
>> significant effect.
>> 
>> ABI stability means that changes will have to be backwards compatible after 
>> a certain stage. If we can add mixins feature without modifying old code 
>> (and its SIL and IR and whatever), then we are fine. 
>> ___
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Goffredo Marocchi via swift-evolution]

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

> On 11 Aug 2016, at 19:09, Kevin Ballard  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  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 
>>>  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
>>> 
>>> The RFC to remove green threading, with motivation: 
>>> https://github.com/aturon/rfcs/blob/remove-runtime/active/-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 

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Kevin Ballard via swift-evolution]

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  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
>>>  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

 The RFC to remove green threading, with motivation:
 https://github.com/aturon/rfcs/blob/remove-runtime/active/-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 

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Goffredo Marocchi via swift-evolution]

+Swift Evolution


By the way, I was genuine when I said thank you because reading how Rust
evolved in those two aspects is very insightful.

On Thu, Aug 11, 2016 at 6:54 PM, 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  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> 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
>>
>> The RFC to remove green threading, with motivation:
>> https://github.com/aturon/rfcs/blob/remove-runtime/active/00
>> 00-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 

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Kevin Ballard via swift-evolution]

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  evolut...@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
>>
>>  The RFC to remove green threading, with motivation:
>>  
>> https://github.com/aturon/rfcs/blob/remove-runtime/active/-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
>>  > > https://lists.swift.org/mailman/listinfo/swift-evolution
>>  ___
>>  swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Goffredo Marocchi via swift-evolution]

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> 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
>
> The RFC to remove green threading, with motivation:
> https://github.com/aturon/rfcs/blob/remove-runtime/
> active/-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
> > > 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

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Kevin Ballard via swift-evolution]

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

The RFC to remove green threading, with motivation: 
https://github.com/aturon/rfcs/blob/remove-runtime/active/-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
> > https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ABI in Layman's terms?

[John McCall via swift-evolution]

> On Aug 11, 2016, at 1:52 AM, Jonathan Hull via swift-evolution 
>  wrote:
> Could someone explain in simple terms what the ABI is and what sorts of 
> things might affect it?

The ABI for a compiled programming language is the set of rules for how all of 
its interoperating features are implemented in the compiled result.

For example, in Java the primary ABI is the JVM specification plus some 
common-sense rules about how language features are mapped to JVM features.  
JVMs do not typically interoperate with other code at a direct binary level, 
and so the details of actual memory layout are not ABI.

Not all language features require interoperation, or only require it a certain 
kind of opaque interoperation.  For example:

  - Type aliases do not currently have any ABI impact because by design they 
are erased at compile time.  However, a complete reflection design might 
provide some mechanism for introspecting type-aliases at runtime, which would 
require information about type aliases to be present in the compiled output; 
the representation of that information would be ABI.

  - Closures in most programming languages do not allow external code to modify 
their captured values; only the closure's invocation function can access them, 
and that is generated together with the capturing code, so the exact 
methodology of performing a capture is not ABI.  However, arbitrary code can 
invoke the closure, and so the opaque representation of a closure value and the 
process for invoking it are ABI.

And so on.

John.

> I had thought it was the layout in memory of structs/classes/etc… and how the 
> program knows where to go to find a particular field.  This seems to be 
> incorrect though, as I have seen many features that I would assume have some 
> affect on this layout ruled “out of scope for phase 1”.  For example, I would 
> think that many generics features would have an impact on the ABI, or the 
> idea of COW (via secret boxing) for structs, or even union types.
> 
> At the very least, I would think that mix-ins would have a fairly significant 
> effect.
> 
> I am obviously missing something here, and I want to provide constructive 
> effort to the community (as opposed to distracting from the task at hand), so 
> I would appreciate some clarification/guidance...
> 
> Thanks,
> Jon
> ___
> 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

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

[Johannes Neubauer via swift-evolution]

Dear Jiannan,

> Am 11.08.2016 um 16:52 schrieb Cao, Jiannan via swift-evolution 
> :
> 
> 
> Some ones proposal have always been accepted very quickly even though it is 
> not fully discussed.
> 
> I don't know why.
> 
> so if some one always focus on swift-evolution then it has more priority to 
> proposal?
> 
> What about others?
> 
> I proposal this since February, May. no one said it is a problem. But in 
> June, some one lead an idea of & and union type proposal has been listed in 
> not-welcomed proposal for Swift 3. No one notify me that discussion and no 
> one discussed that with me. I try to discuss with the core team but they have 
> no response before June. But After June, they said it is not for Swift 3. OK, 
> I proposed for Swift 4, and get a shit response.
> 
> Email list let proposal topic hide themselves?
> 
> No direct answer of my Feb, May proposal, but a June discussed sometime 
> somewhere I don't know.
> 
> so I make a proposal, and this is the result.

In parts I can understand your frustration although your kind of reaction cuts 
everybody’s slack, because it is well behind rules of politeness/netiquette 
whatever. I think it is „normal“ that more active members that have provided 
good input already get automatically some bonus, even if it was not intended. 
Its just human.

I am quite new here and tried to add some value to discussions where I have 
confidence and I had the slight feeling that sometimes people that are more 
involved in the evolution process take a quick, vague look at my text and 
answer with some very generic and devastating commentary. This can be 
frustrating, but still it is a normal thing.

In Kotlin’s evolution process they use different media for different stadium of 
discussion (which has been proposed here too) and for each stadium they start 
to introduce a given process (the procedure is work in progress). Currently, 
there it is like this:

* discuss on Slack to get a feeling whether community gives some response 
(nobody expects that you look back for months in that history)
* create an issue in their issue tracker for further discussions
* if you get a *go* from the core team create a proposal (with a very similar 
format as the proposals have here) and create a pull request
* after some discussion you may either abandon your proposal or try to get a so 
called „shepherd“ from the core team
* from now on the shepherd guides the discussion

I didn’t get further than this yet, so I don’t know whether they have a 
community voting procedure, but it would be a nice addition.

Perhaps such a more guided (and comprehensible) procedure would help to keep 
track and make the process more fair (since the goal is to make swift better 
not to support personal self-affirmation like e.g. the german wikipedia 
administrators do).

All the best
Johannes

> 在 2016年8月11日，21:42，Wallacy  写道：
> 
>> You don't need to act like a jerk. It's really difficult ask to you follow 
>> the past discussions?
>> 
>> Compositions type are "generally" well accepted for this community, but has 
>> some problems to be solved first.
>> 
>> 
>> Em qui, 11 de ago de 2016 às 02:53, Cao, Jiannan via swift-evolution 
>>  escreveu:
>> OK. I'll shut up since I waste your time.
>> 
>> At 2016-08-11 13:41:59, "Chris Lattner"  wrote:
>> You’re certainly welcome to your opinion.
>> 
>> Swift is not Typescript, and this topic has been discussed extensively in 
>> the past.  We expect you to familiarize yourself with those discussions.  
>> Otherwise, it is just a waste of people’s time to rehash old arguments.
>> 
>>> On Aug 10, 2016, at 10:22 PM, Cao, Jiannan  wrote:
>>> 
>>> Swift evolution seems not an evolution.
>>> 
>>> I'll leave this mail list since this is not a good proposal environment. 
>>> Typescript and other language community is more open to new idea. 
>>> Swift-evolution is just a weird community.
>>> 
>>> 在 2016-08-11 13:18:54，"Chris Lattner"  写道：
>>> 
 On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution 
  wrote:
 
 I don't know if the core team feels differently now with respect to Swift 
 4, but union types are listed as a "commonly rejected change":
 
 https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
>>> 
>>> There is no change in opinion here.  This topic is also out of scope for 
>>> Swift 4 stage 1 in any case.
>>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

[Cao, Jiannan via swift-evolution]

Some ones proposal have always been accepted very quickly even though it is not 
fully discussed.

I don't know why.

so if some one always focus on swift-evolution then it has more priority to 
proposal?

What about others?

I proposal this since February, May. no one said it is a problem. But in June, 
some one lead an idea of & and union type proposal has been listed in 
not-welcomed proposal for Swift 3. No one notify me that discussion and no one 
discussed that with me. I try to discuss with the core team but they have no 
response before June. But After June, they said it is not for Swift 3. OK, I 
proposed for Swift 4, and get a shit response. 

Email list let proposal topic hide themselves?

No direct answer of my Feb, May proposal, but a June discussed sometime 
somewhere I don't know.

so I make a proposal, and this is the result.





> 在 2016年8月11日，21:42，Wallacy  写道：
> 
> You don't need to act like a jerk. It's really difficult ask to you follow 
> the past discussions?
> 
> Compositions type are "generally" well accepted for this community, but has 
> some problems to be solved first.
> 
> 
>> Em qui, 11 de ago de 2016 às 02:53, Cao, Jiannan via swift-evolution 
>>  escreveu:
>> OK. I'll shut up since I waste your time.
>> 
>> At 2016-08-11 13:41:59, "Chris Lattner"  wrote:
>> You’re certainly welcome to your opinion.  
>> 
>> Swift is not Typescript, and this topic has been discussed extensively in 
>> the past.  We expect you to familiarize yourself with those discussions.  
>> Otherwise, it is just a waste of people’s time to rehash old arguments.
>> 
>> -Chris
>> 
>> 
>>> On Aug 10, 2016, at 10:22 PM, Cao, Jiannan  wrote:
>>> 
>> 
>>> Swift evolution seems not an evolution. 
>>> 
>>> I'll leave this mail list since this is not a good proposal environment. 
>>> Typescript and other language community is more open to new idea. 
>>> Swift-evolution is just a weird community. 
>>> 
>> 
 在 2016-08-11 13:18:54，"Chris Lattner"  写道：
 
 On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution 
  wrote:
 
 I don't know if the core team feels differently now with respect to Swift 
 4, but union types are listed as a "commonly rejected change":
 
 https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
>>> 
>>> There is no change in opinion here.  This topic is also out of scope for 
>>> Swift 4 stage 1 in any case.
>>> 
>>> -Chris
>> 
>> 
>>  
>> 
>> ___
>> 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

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Dave Abrahams via swift-evolution]

Sent from my moss-covered three-handled family gradunza

> On Aug 11, 2016, at 7:14 AM, Ben Rimmington  wrote:
> 
> 
>>> On 11 Aug 2016, at 00:24, Brent Royal-Gordon wrote:
>>> 
>>> On Aug 9, 2016, at 12:09 PM, Dave Abrahams wrote:
>>> 
>>> Deprecate the Indexable protocols with a message indicating that they
>>> will be gone in Swift 4.
>> 
>> Should IndexableBase get the same treatment?
> 
> Yes, see  from the SE-0137 proposal.
> 
> 

What he said!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Ben Rimmington via swift-evolution]

> On 11 Aug 2016, at 00:24, Brent Royal-Gordon wrote:
> 
>> On Aug 9, 2016, at 12:09 PM, Dave Abrahams wrote:
>> 
>> Deprecate the Indexable protocols with a message indicating that they
>> will be gone in Swift 4.
> 
> Should IndexableBase get the same treatment?

Yes, see  from the SE-0137 proposal.



-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

[Wallacy via swift-evolution]

You don't need to act like a jerk. It's really difficult ask to you follow
the past discussions?

Compositions type are "generally" well accepted for this community, but has
some problems to be solved first.


Em qui, 11 de ago de 2016 às 02:53, Cao, Jiannan via swift-evolution <
swift-evolution@swift.org> escreveu:

> OK. I'll shut up since I waste your time.
>
> At 2016-08-11 13:41:59, "Chris Lattner"  wrote:
>
> You’re certainly welcome to your opinion.
>
> Swift is not Typescript, and this topic has been discussed extensively in
> the past.  We expect you to familiarize yourself with those discussions.
> Otherwise, it is just a waste of people’s time to rehash old arguments.
>
> -Chris
>
> On Aug 10, 2016, at 10:22 PM, Cao, Jiannan  wrote:
>
> Swift evolution seems not an evolution.
>
> I'll leave this mail list since this is not a good proposal environment.
> Typescript and other language community is more open to new idea.
> Swift-evolution is just a weird community.
>
> 在 2016-08-11 13:18:54，"Chris Lattner"  写道：
>
>
> On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I don't know if the core team feels differently now with respect to Swift
> 4, but union types are listed as a "commonly rejected change":
>
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
>
>
> There is no change in opinion here.  This topic is also out of scope for
> Swift 4 stage 1 in any case.
>
> -Chris
>
>
>
>
> ___
> 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

[swift-evolution] Use lowerCamelCase for @warn_unqualified_access attribute?

[Ben Rimmington via swift-evolution]

I noticed that the @warn_unqualified_access attribute in LibraryEvolution 
hasn't been updated to lowerCamelCase.



It's currently used by the `min` and `max` methods of Sequence, and the `print` 
methods in AppKit.





It doesn't have the UserInaccessible option, so can @warn_unqualified_access 
also be used in client code?



-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ABI in Layman's terms?

[Charlie Monroe via swift-evolution]

This article has helped me a lot:

https://github.com/apple/swift/blob/master/docs/ABI.rst 


And generally all the documents in the docs folder will paint a nice picture of 
what to expect. Not that I would say that I fully understand the ABI, but I 
think that after reading all the docs I will have a better way of understanding 
what to expect.

> On Aug 11, 2016, at 1:33 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Right, I understand that part.  ABI stability means that we can run past 
> binaries without recompiling.
> 
> What I want to know is what sorts of things affect this stability and which 
> things don’t.  I guess I want heuristics for knowing whether an idea will 
> affect the ABI, and thus needs to be talked about now.  I don’t want to 
> distract from the process by proposing features which can be tackled later, 
> but at the same time I REALLY don’t want to wait until phase 2 and then be 
> told the feature can never be added because it would break the ABI (and I 
> should have proposed it during phase 1).
> 
> Thanks,
> Jon
> 
>> On Aug 11, 2016, at 4:24 AM, Anton Zhilin > > wrote:
>> 
>> 2016-08-11 11:52 GMT+03:00 Jonathan Hull via swift-evolution 
>> >:
>> Could someone explain in simple terms what the ABI is and what sorts of 
>> things might affect it?
>> 
>> I had thought it was the layout in memory of structs/classes/etc… and how 
>> the program knows where to go to find a particular field.  This seems to be 
>> incorrect though, as I have seen many features that I would assume have some 
>> affect on this layout ruled “out of scope for phase 1”.  For example, I 
>> would think that many generics features would have an impact on the ABI, or 
>> the idea of COW (via secret boxing) for structs, or even union types.
>> 
>> At the very least, I would think that mix-ins would have a fairly 
>> significant effect.
>> 
>> ABI stability means that changes will have to be backwards compatible after 
>> a certain stage. If we can add mixins feature without modifying old code 
>> (and its SIL and IR and whatever), then we are fine. 
> 
> ___
> 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

Re: [swift-evolution] ABI in Layman's terms?

[Jonathan Hull via swift-evolution]

Right, I understand that part.  ABI stability means that we can run past 
binaries without recompiling.

What I want to know is what sorts of things affect this stability and which 
things don’t.  I guess I want heuristics for knowing whether an idea will 
affect the ABI, and thus needs to be talked about now.  I don’t want to 
distract from the process by proposing features which can be tackled later, but 
at the same time I REALLY don’t want to wait until phase 2 and then be told the 
feature can never be added because it would break the ABI (and I should have 
proposed it during phase 1).

Thanks,
Jon

> On Aug 11, 2016, at 4:24 AM, Anton Zhilin  wrote:
> 
> 2016-08-11 11:52 GMT+03:00 Jonathan Hull via swift-evolution 
> >:
> Could someone explain in simple terms what the ABI is and what sorts of 
> things might affect it?
> 
> I had thought it was the layout in memory of structs/classes/etc… and how the 
> program knows where to go to find a particular field.  This seems to be 
> incorrect though, as I have seen many features that I would assume have some 
> affect on this layout ruled “out of scope for phase 1”.  For example, I would 
> think that many generics features would have an impact on the ABI, or the 
> idea of COW (via secret boxing) for structs, or even union types.
> 
> At the very least, I would think that mix-ins would have a fairly significant 
> effect.
> 
> ABI stability means that changes will have to be backwards compatible after a 
> certain stage. If we can add mixins feature without modifying old code (and 
> its SIL and IR and whatever), then we are fine. 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ABI in Layman's terms?

[David Hart via swift-evolution]

I'd also like to understand this more and this answer does not completely 
satisfy me. I understand backwards compatibility, especially in terms of source 
breaking changes.

I have more difficulties understanding what breaks or not the ABI and how to 
make educated guesses about what features will require breaking it.

> On 11 Aug 2016, at 13:24, Anton Zhilin via swift-evolution 
>  wrote:
> 
> 2016-08-11 11:52 GMT+03:00 Jonathan Hull via swift-evolution 
> :
>> Could someone explain in simple terms what the ABI is and what sorts of 
>> things might affect it?
>> 
>> I had thought it was the layout in memory of structs/classes/etc… and how 
>> the program knows where to go to find a particular field.  This seems to be 
>> incorrect though, as I have seen many features that I would assume have some 
>> affect on this layout ruled “out of scope for phase 1”.  For example, I 
>> would think that many generics features would have an impact on the ABI, or 
>> the idea of COW (via secret boxing) for structs, or even union types.
>> 
>> At the very least, I would think that mix-ins would have a fairly 
>> significant effect.
> 
> ABI stability means that changes will have to be backwards compatible after a 
> certain stage. If we can add mixins feature without modifying old code (and 
> its SIL and IR and whatever), then we are fine. 
> ___
> 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

Re: [swift-evolution] ABI in Layman's terms?

[Anton Zhilin via swift-evolution]

2016-08-11 11:52 GMT+03:00 Jonathan Hull via swift-evolution <
swift-evolution@swift.org>:

> Could someone explain in simple terms what the ABI is and what sorts of
> things might affect it?
>
> I had thought it was the layout in memory of structs/classes/etc… and how
> the program knows where to go to find a particular field.  This seems to be
> incorrect though, as I have seen many features that I would assume have
> some affect on this layout ruled “out of scope for phase 1”.  For example,
> I would think that many generics features would have an impact on the ABI,
> or the idea of COW (via secret boxing) for structs, or even union types.
>
> At the very least, I would think that mix-ins would have a fairly
> significant effect.


ABI stability means that changes will have to be backwards compatible after
a certain stage. If we can add mixins feature without modifying old code
(and its SIL and IR and whatever), then we are fine.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] ABI in Layman's terms?

[Jonathan Hull via swift-evolution]

Could someone explain in simple terms what the ABI is and what sorts of things 
might affect it?

I had thought it was the layout in memory of structs/classes/etc… and how the 
program knows where to go to find a particular field.  This seems to be 
incorrect though, as I have seen many features that I would assume have some 
affect on this layout ruled “out of scope for phase 1”.  For example, I would 
think that many generics features would have an impact on the ABI, or the idea 
of COW (via secret boxing) for structs, or even union types.

At the very least, I would think that mix-ins would have a fairly significant 
effect.

I am obviously missing something here, and I want to provide constructive 
effort to the community (as opposed to distracting from the task at hand), so I 
would appreciate some clarification/guidance...

Thanks,
Jon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Dan Stenmark via swift-evolution]

> On Aug 10, 2016, at 10:24 PM, Chris Lattner  wrote:
> 
> Hi Dan,
> 
> There are many folks interested in concurrency topics related to this, but we 
> need to stay focused on finishing Swift 3 and then moving on to Swift 4 stage 
> 1 goals.  As that work is cresting, we’ll start discussions of concurrency, 
> and may even be so bold as to start a new mailing list dedicated to the 
> topic, since it is such a wide reaching topic.
> 
> Until we get to that point, please resist the urge to jump ahead :-)
> 
> -Chris

Chris, many apologies if this came across the wrong way!  As I attempted to 
explain in the opening email, I'm inquiring for purely academic reasons and to 
better my understanding of concurrency as part of language design in general, 
not to pitch anything for Swift.  In retrospect, perhaps -users would've been a 
better fit for this question rather than -evolution.


> On Aug 9, 2016, at 1:59 PM, Joe Groff via swift-evolution 
>  wrote:
> 
>> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution 
>>  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).

This right here is what I was looking for.  Thanks, guys!

Dan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution