Swift concurrency – things they don’t tell you(wojciechkulik.pl) |
Swift concurrency – things they don’t tell you(wojciechkulik.pl) |
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.
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.
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.