> On Aug 25, 2017, at 9:54 AM, Thomas <tclement...@free.fr> wrote:
>
> I'd tend to think non-FIFO actor messaging will cause more trouble than
> potential deadlocks. I'm re-reading the proposal and it seems to go this way
> as well:
>
> "An await on an actor method suspends the current task, and since you can get
> circular waits, you can end up with deadlock. This is because only one
> message is processed by the actor at a time. The trivial case like this can
> also be trivially diagnosed by the compiler. The complex case would ideally
> be diagnosed at runtime with a trap, depending on the runtime implementation
> model."
I understand what you’re saying, but I just think trying to make synchronous,
blocking actor methods goes against the fundamental ideal of the actor model,
and it’s a recipe for disaster. When actors communicate with each other that
communication needs to be asynchronous or you will get deadlocks. It’s not just
going to be a corner case. It’s going to be a very frequent occurrence.
One of the general rules of multithreaded programming is “don’t call unknown
code while holding a lock”. Blocking a queue is effectively the same as holding
a lock, and calling another actor is calling unknown code. So if the model
works that way then the language itself will be encouraging people to call
unknown code while holding locks. That is not going to go well.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
