top | item 33379414

Swift concurrency – things they don’t tell you

28 points| teichmann | 3 years ago |wojciechkulik.pl

7 comments

order

cvwright|3 years ago

I really enjoy working in Swift these days, and async/await has been a huge blessing.

But the whole way that Actors were rolled out leaves a funny taste.

Apple’s main illustrating example for using an Actor was to update a database. But if you try to do that, you run into exactly the same reentrancy issue described in this article!

While your Actor function is await’ing on the database, you can have another call to the same function start running, trying to write a different value to the DB. Now you have a race condition — exactly the kind of pain that Actors were supposed to save us from.

WTF Apple?!?

It would be ok if the first version was presented as a stepping stone to greater things. Instead they piss on our heads and tell us it’s raining.

morsch|3 years ago

Updating databases (e.g. views) is a common thing we do using Akka actors. While a DB call is running, you store incoming updates in a local var, and once the DB update is done, you start the next DB update with the whole batch. So you never have more than one concurrent DB call, and there is no race condition. This all fits in quite well into the actor model.

pjmlp|3 years ago

It is kind of interesting to see all ecosystems that have adopted async/await to go through the same pain points as we have in .NET.

It took from .NET 4.5 up to .NET 5 (don't forget the whole .NET Core transition in the middle), to sort out the async/await across all possible workflows, and after all this, they started to consider also adding virtual threads support due to the colouring aspect of it.

johnthescott|3 years ago

golang is atomic message passing (although async/await exist).