> On 25 Aug 2017, at 10:14, Thomas via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On 25 Aug 2017, at 01:15, Adam Kemp <adam.k...@apple.com >> <mailto:adam.k...@apple.com>> wrote: >> >> >> >>> On Aug 24, 2017, at 3:15 PM, Thomas <tclement...@free.fr >>> <mailto:tclement...@free.fr>> wrote: >>> >>> >>>> On 24 Aug 2017, at 23:47, Adam Kemp <adam.k...@apple.com >>>> <mailto:adam.k...@apple.com>> wrote: >>>> >>>> >>>>> On Aug 24, 2017, at 1:05 PM, Thomas via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>>> >>>>>> On 24 Aug 2017, at 21:48, Marc Schlichte <marc.schlic...@googlemail.com >>>>>> <mailto:marc.schlic...@googlemail.com>> wrote: >>>>>> >>>>>> Yes, I think it is mandatory that we continue on the callers queue after >>>>>> an `await ` on some actor method. >>>>>> >>>>>> If you `await` on a non-actor-method though, you would have to changes >>>>>> queues manually if needed. >>>>>> >>>>>> Any `actor` should have a `let actorQueue: DispatchQueue` property so >>>>>> that we can call in these cases: >>>>>> >>>>>> ```await actorQueue.asyncCoroutine()``` as mentioned in the manifesto. >>>>> >>>>> Wouldn't that be really confusing though? That awaiting certain methods >>>>> would bring us back to the actor's queue but awaiting others would >>>>> require manual queue hopping? What if the compiler was to always generate >>>>> the 'await actorQueue.asyncCoroutine()' queue hopping code after awaiting >>>>> on an async/actor method? >>>> >>>> Yes, it would be confusing. await should either always return to the same >>>> queue or never do it. Otherwise it’s even more error-prone. I see the >>>> actor feature as being just another demonstration of why solving the >>>> queue-hopping problem is important for async/await to be useful. >>> >>> So the way a non "fire and forget" actor method would work is: >>> >>> - the actor's queue is in a suspended state until the method returns, this >>> is required so that messages sent to other actor methods are not processed >>> (they're added to the queue) >>> - if the method body awaits on some other code, it automatically jumps back >>> on the actor's queue after awaiting, regardless of the queue's suspension >>> and content >>> - when the method returns, the actor's queue is resumed and pending >>> messages can be processed (if any) >>> >> >> 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”. :) > > It is correct that suspending the queue allows for deadlocks, but not doing > it means you can receive messages while still in the middle of another > message. For the same reason you may need FIFO ordering in a class to > guarantee coherency, you will want this to work in an asynchronous world as > well. Take for example some storage class: > > 1. store(object, key) > 2. fetch(key) > > If you're doing these operations in order, you want the fetch to return the > object you just stored. If the 'store' needs to await something in its > implementation and we were to not suspend the queue, the fetch would be > processed before the object is actually stored and it would return something > unexpected.
By the way, contrary to what I said earlier, that means we'd need to do this also for "fire and forget" methods, as is "store" in this example.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
