[swift-evolution] [Concurrency] async/await + actors

[Howard Lovatt]

To avoid or at least detect deadlocks you need: timeout (which will at
least generate an error), cancel (which will prevent zombie processes), and
status information (for debugging). It doesn’t make any difference if the
reference is strong or weak. There is an advantage in strong references
since you can fire and forget if you want a deamon process that is totally
self managing.

On Sun, 27 Aug 2017 at 12:53 am, Marc Schlichte via swift-evolution <
swift-evolution at swift.org> wrote:

> Am 26.08.2017 um 02:03 schrieb Adam Kemp via swift-evolution <
> swift-evolution at swift.org>:
>
> I’m not sure I understand. What is the connection between references and
> deadlocks?
>
>
>
> This is what I had in mind:
>
> To have a deadlock from async actor methods, you would need some mutual
> invocations of them - i.e a cycle in the call graph.
>
> If your code is (strong) retain cycle free and you make invocations only
> on actors of which you have strong references, you will also have no cyclic
> call graph, hence no deadlocks.
>
>
> Now, unfortunately - and contrary to my claim - deadlocks still can happen:
>
> if you `await` in your async actor method on some state which can only be
> set via another actor method in your actor, a deadlock occurs:
>
> Example:
> ```
> actor class A {
>   var continuation: (() -> Void)?
>   actor func m1() async {
>     await suspendAsync { cont in
>       continuation = cont
>     }
>   }
>   actor func m2() {
>     continuation?()
>   }
> }
> ```
>
> If someone calls `a.m1()`, and someone else `a.m2()`, `a.m1()` still does
> not complete as `a.m2()` is not allowed to run while `a.m1()` is not
> finished.
>
> Marking `m2` as an `interleaved actor func` would remedy that situation as
> it could then run when the next work item is picked from the serial gdc
> queue - which can happen while we `await` on the `suspendAsync` in the
> example above.
>
>
> Cheers
> Marc
>
>
> On Aug 25, 2017, at 1:07 PM, Marc Schlichte <marc.schlichte at googlemail.com>
> wrote:
>
>
> Am 25.08.2017 um 19:08 schrieb Adam Kemp via swift-evolution <
> swift-evolution at swift.org>:
>
> 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.
>
>
> I would claim - without having a prove though - that as long as you don’t
> invoke async actor methods on weak or unowned actor references and the code
> is retain cycle free, no deadlocks will happen.
>
> Cheers
> Marc
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170827/f6cdec72/attachment.html>