> Am 25.08.2017 um 01:15 schrieb Adam Kemp via swift-evolution > <[email protected]>: > > I don’t think await should cause the actor’s queue (or any queue) to be > suspended. Actor methods should not block waiting for asynchronous things. > That’s how you get deadlocks. If an actor method needs to be async then it > should work just like any async method on the main queue: it unblocks the > queue and allows other messages to be processed until it gets an answer. > > You do have to be aware of the fact that things can happen in between an > await and the next line of code, but conveniently these places are all marked > for you. They all say “await”. :)
Yes, that is important to note: when we `await` on an `async` method, the callers queue does not get blocked in any way. The control flow just continues - with the next instruction after the enclosing `beginAsync` I suppose - and when done with the current DispatchWorkItem just dequeues the next DispatchWorkItem and works on it. If there is no next item, the underlying thread might still not be suspend but be used to work on some another queue. Despite that, we might still want to discuss if actor-methods should get serialized beyond that - think of an underlying GCD queue (as discussed above) and a separate (non-GDC) message-queue where actor messages will get queued up. In another thread I proposed to introduce a new modifier for actor methods which will not put them into the message-queue and which are thus allowed to run whenever the GCD queue picks them up: serialized by message-queue: `actor func foo() async` non-serialized: `interleaved actor func bar() async` This way, when you reason about your code and look at places marked with `await`, only `interleaved` methods (or code using explicit `beginAsync` calls) might have changed your state. Cheers Marc
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
