Isolated and failable green threads?


(Niklas Saers) #1

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?

Cheers

    Nik

[0]: https://en.wikipedia.org/wiki/Green_threads
[1]: http://erlang.org/doc/design_principles/sup_princ.html
[2]: https://en.wikipedia.org/wiki/Actor_model


(Brent Royal-Gordon) #2

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?

Mainly, that concurrency is out of scope for Swift 3 (https://github.com/apple/swift-evolution/blob/master/README.md#out-of-scope). Hang in there, though. :^)

···

--
Brent Royal-Gordon
Architechies


(Austin Zheng) #3

No idea what validity this has now, if any, but there's an elegant model described in this document: https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst.

Austin

···

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?

Mainly, that concurrency is out of scope for Swift 3 (https://github.com/apple/swift-evolution/blob/master/README.md#out-of-scope). Hang in there, though. :^)

--
Brent Royal-Gordon
Architechies

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


(Chris Lattner) #4

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:

No idea what validity this has now, if any, but there's an elegant model described in this document: https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst.


(Fabian Balslev Saers) #5

Hi Brent, Austin and Chris, thank you very much for your quick response,

Mainly, that concurrency is out of scope for Swift 3 (https://github.com/apple/swift-evolution/blob/master/README.md#out-of-scope). Hang in there, though. :^)

Thanks for clarifying, Brent.

No idea what validity this has now, if any, but there's an elegant model described in this document: https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst.

Thank you soo much for the link, I had not seen this. I really like what I’m reading here. :slight_smile:

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. :slight_smile:

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:


(Chris Lattner) #6

This is a limitation in the generics system "Conditional conformances via constrained extensions”. The goal is to get this implemented in Swift 3.

-Chris

···

On Jan 28, 2016, at 11:51 PM, Fabian Balslev Saers via swift-evolution <swift-evolution@swift.org> wrote:

Hi Brent, Austin and Chris, thank you very much for your quick response,

On 28 Jan 2016, at 09:31, Brent Royal-Gordon <brent@architechies.com <mailto:brent@architechies.com>> wrote:
Mainly, that concurrency is out of scope for Swift 3 (https://github.com/apple/swift-evolution/blob/master/README.md#out-of-scope). Hang in there, though. :^)

Thanks for clarifying, Brent.

On 28 Jan 2016, at 09:36, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:
No idea what validity this has now, if any, but there's an elegant model described in this document: https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst.

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)