Hi all,
thank you all soo much for taking the time to make Swift such a great language, so that I get to use it smiling for all my work.
There are two concepts from Erlang that I really like:
- threads are very light-weight ([green threads][0]), and memory cannot be accessed accross threads (isolated threads)
- when a thread dies, the entire app doesn't crash, but the nearest [supervisor][1] cleans up and can re-launch a new thread
Applying this to apps written in Swift, I would expect would lead to
- fewer app crashes
- developers become more likely to architecture their app by using the [actor model][2]
I am sure these ideas are not new here, but I couldn't find a discussion on it by searching the archive. What are your thoughts on bringing isolated green threads that are allowed to crash to Swift?
There are two concepts from Erlang that I really like:
- threads are very light-weight ([green threads][0]), and memory cannot be accessed accross threads (isolated threads)
- when a thread dies, the entire app doesn't crash, but the nearest [supervisor][1] cleans up and can re-launch a new thread
Applying this to apps written in Swift, I would expect would lead to
- fewer app crashes
- developers become more likely to architecture their app by using the [actor model][2]
I am sure these ideas are not new here, but I couldn't find a discussion on it by searching the archive. What are your thoughts on bringing isolated green threads that are allowed to crash to Swift?
On Jan 28, 2016, at 12:31 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
There are two concepts from Erlang that I really like:
- threads are very light-weight ([green threads][0]), and memory cannot be accessed accross threads (isolated threads)
- when a thread dies, the entire app doesn't crash, but the nearest [supervisor][1] cleans up and can re-launch a new thread
Applying this to apps written in Swift, I would expect would lead to
- fewer app crashes
- developers become more likely to architecture their app by using the [actor model][2]
I am sure these ideas are not new here, but I couldn't find a discussion on it by searching the archive. What are your thoughts on bringing isolated green threads that are allowed to crash to Swift?
Yep: it is a well thought out approach, but it is also certainly not plan of record - it is just an idea - just like the other stuff in docs/proposals.
I expect concurrency to be a major focus for Swift 4, but we need to get Swift 3 done first. :-)
-Chris
···
On Jan 28, 2016, at 12:36 AM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:
Thank you soo much for the link, I had not seen this. I really like what I’m reading here. :-)
Yep: it is a well thought out approach, but it is also certainly not plan of record - it is just an idea - just like the other stuff in docs/proposals.
I expect concurrency to be a major focus for Swift 4, but we need to get Swift 3 done first. :-)
Absolutely
One part I didn’t understand from the proposal was this:
“Notice that due to rdar://17144340 we still can't mark Arrays and Optionals as copyable”
Could someone explain that to me (I don’t think I have access to that radar)
This document deals with how to make the threads isolated, which I think lays the groundwork for making threads able to be cleaned up if they crash, without taking the system with it. But I didn’t see a proposal of how to deal with this situation. Is there a similar document you could refer me to that deals with this?
Cheers
Nik
···
On 28 Jan 2016, at 09:31, Brent Royal-Gordon <brent@architechies.com> wrote:
On 28 Jan 2016, at 09:36, Austin Zheng <austinzheng@gmail.com> wrote:
On 28 Jan 2016, at 19:04, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Thank you soo much for the link, I had not seen this. I really like what I’m reading here. :-)
On 28 Jan 2016, at 19:04, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Yep: it is a well thought out approach, but it is also certainly not plan of record - it is just an idea - just like the other stuff in docs/proposals.
I expect concurrency to be a major focus for Swift 4, but we need to get Swift 3 done first. :-)
Absolutely
One part I didn’t understand from the proposal was this:
“Notice that due to rdar://17144340 <rdar://17144340> we still can't mark Arrays and Optionals as copyable”
Could someone explain that to me (I don’t think I have access to that radar)