[swift-evolution] Isolated and failable green threads?

Austin Zheng austinzheng at gmail.com
Thu Jan 28 02:36:09 CST 2016


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 <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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160128/13bfc963/attachment.html>


More information about the swift-evolution mailing list