[cvwright]

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]

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.

[mrkeen]

Actor's claim to fame is no race conditions because no shared state. Haven't you just reintroduced shared state with that approach?

[morsch]

No. I've introduced state, but no shared state; the "next batch" var is local to the actor and not shared.

Critically, the only one who updates the variable is the actor itself in its thread; it could be a plain list, and not a concurrent queue as it might be in a different multiple producer/single consumer architecture.

PS -- I'll add that in Akka itself, the actor's mailbox, in which messages accumulate until the actor next gets allotted a thread, is exactly a kind of concurrent queue, at least in its default implementation.