What about concurrency?


(Anton Mironov) #1

Hi,

My job is mostly consists of writing core functionality for macOS (and I love core functionality). My code must take advantage of concurrency. I've been looking for solutions that allow me to write clean and (most important) reliable concurrent code. I would love to discuss some of those solutions and find out if they are any close to what Swift team want to implement in Swift 4+.

1. using actors
Actor (in this context) is a stateful object that owns private serial queue and performs all changes of internal state on that queue. In my opinion, it fits into actor model https://en.wikipedia.org/wiki/Actor_model (where a mailbox is an internal queue). So 95% of classes I make are folding into two categories: concurrency-aware actors and other objects that are made for single threaded usage.
There is a very common corner case of NSResponder/UIResponder (view controllers, windows, views, quartz core layers and etc) but they are basically components of some imaginary global actor that live on the main queue.
I also want to thank Apple team for adding dispatchPrecondition(...) function that helps me to detect if I accidently called agent`s private method on the wrong queue.

2. using futures (and streams) instead of callbacks
It saved me from callback hell and helped me to avoid some common issues (such as forgetting to call the callback in some error-handling related cases). The most convincing thing to me was a way of combining multiple futures together. It is far simpler and safer than using group or barrier.
I've used FutureKit for utility app that has a lot of concurrency and it served me very well. Now I am trying to implement something like it for Swift 3 with more strict error handling and with streams.

3. no atomic properties and locks (except for locks in FutureKit)
I've learned the hard way that locks are making a lot of troubles. So now I am free from them and I am very glad about it.
I also want to thank Swift team for not adding @synchronized to Swift because this decision is really cleaned my mind.

So what do you think?

Thanks,
Anton Mironov


(Chris Lattner) #2

Hi Anton,

Many people have thoughts and opinions on this (some held very strong, some not so much). We hope to kick off discussions about concurrency sometime after the Swift 4 stage 1 projects are complete (with the tentative goal of getting a baked concurrency story into Swift 5).

In the meantime, we’re prefer to stay focused on getting Swift 3 out the door, then move on the Swift 4 stage 1. Thanks!

-Chris

···

On Sep 4, 2016, at 3:00 PM, Anton Mironov via swift-dev <swift-dev@swift.org> wrote:

My job is mostly consists of writing core functionality for macOS (and I love core functionality). My code must take advantage of concurrency. I've been looking for solutions that allow me to write clean and (most important) reliable concurrent code. I would love to discuss some of those solutions and find out if they are any close to what Swift team want to implement in Swift 4+.


(Anton Mironov) #3

7 вер. 2016 р. о 03:05 Chris Lattner <clattner@apple.com> написав(ла):

My job is mostly consists of writing core functionality for macOS (and I love core functionality). My code must take advantage of concurrency. I've been looking for solutions that allow me to write clean and (most important) reliable concurrent code. I would love to discuss some of those solutions and find out if they are any close to what Swift team want to implement in Swift 4+.

Hi Anton,

Many people have thoughts and opinions on this (some held very strong, some not so much). We hope to kick off discussions about concurrency sometime after the Swift 4 stage 1 projects are complete (with the tentative goal of getting a baked concurrency story into Swift 5).

In the meantime, we’re prefer to stay focused on getting Swift 3 out the door, then move on the Swift 4 stage 1. Thanks!

-Chris

Hi Chris,

Thank you for your response. Focusing on Swift 3 and goals for Swift 4 stage 1 are definitely more important than concurrency in any possible way.

On the other hand, concurrency is still a very important aspect for most of apps. We just cannot live without it. It might be two years from now till standardized concurrency will be in Xcode GM seed. For all this time we are bound to use own solutions.

The great thing about implementing concurrency is that it can be tried out in parallel with Swift 3 and Swift 4 development. Maybe as a Swift users community we can discuss and try out some solutions that do not require any/much language support. This will give us well-discussed concurrency implementations much earlier. It will also provide real world testing of these solutions before Swift team implementation and engraving solutions into the standard.

Thanks,
Anton Mironov

···

On Sep 4, 2016, at 3:00 PM, Anton Mironov via swift-dev <swift-dev@swift.org> wrote: