> Le 25 sept. 2017 à 18:54, Trevör Anne Denise via swift-evolution > <swift-evolution@swift.org> a écrit : > >> >> Le 25 sept. 2017 à 13:33, Trevör ANNE DENISE <trevor.anneden...@icloud.com >> <mailto:trevor.anneden...@icloud.com>> a écrit : >> >> >> Le 25 sept. 2017 à 11:55, Thomas <tclement...@free.fr >> <mailto:tclement...@free.fr>> a écrit : >> >>> >>>> On 25 Sep 2017, at 10:23, Trevör Anne Denise via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> >>>>> Le 24 sept. 2017 à 12:00, Jean-Daniel <mail...@xenonium.com >>>>> <mailto:mail...@xenonium.com>> a écrit : >>>>> >>>>> >>>>> >>>>>> Le 23 sept. 2017 à 12:23, Trevör Anne Denise via swift-evolution >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >>>>>> >>>>>> >>>>>>> Le 20 sept. 2017 à 21:15, Jean-Daniel <mail...@xenonium.com >>>>>>> <mailto:mail...@xenonium.com>> a écrit : >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Le 20 sept. 2017 à 08:36, Trevör Anne Denise via swift-evolution >>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit >>>>>>>> : >>>>>>>> >>>>>>>>> >>>>>>>>> Le 18 sept. 2017 à 18:07, Pierre Habouzit <pie...@habouzit.net >>>>>>>>> <mailto:pie...@habouzit.net>> a écrit : >>>>>>>>> >>>>>>>>> >>>>>>>>> -Pierre >>>>>>>>> >>>>>>>>>> On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise >>>>>>>>>> <trevor.anneden...@icloud.com <mailto:trevor.anneden...@icloud.com>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Le 18 sept. 2017 à 07:57, Pierre Habouzit <pie...@habouzit.net >>>>>>>>>>> <mailto:pie...@habouzit.net>> a écrit : >>>>>>>>>>> >>>>>>>>>>>> On Sep 17, 2017, at 3:52 AM, Trevör ANNE DENISE via >>>>>>>>>>>> swift-evolution <swift-evolution@swift.org >>>>>>>>>>>> <mailto:swift-evolution@swift.org>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello everyone, >>>>>>>>>>>> >>>>>>>>>>>> I have a few questions about async await in Swift. >>>>>>>>>>>> >>>>>>>>>>>> Say that you have : >>>>>>>>>>>> >>>>>>>>>>>> func foo() async { >>>>>>>>>>>> print("Hey") >>>>>>>>>>>> await bar() >>>>>>>>>>>> print("How are you ?") >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> First of all, am I right to say that : >>>>>>>>>>>> 1) If the bar function wasn't an async function, the thread would >>>>>>>>>>>> be blocked until bar returns, at this point print("How are you ?") >>>>>>>>>>>> would be executed and its only after that that the function >>>>>>>>>>>> calling foo() would get back "control" >>>>>>>>>>> >>>>>>>>>>> I don't think you can quite call await without marking foo() as >>>>>>>>>>> async (?). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes, that's what I meant, case one would call foo() without await if >>>>>>>>>> it wasn't async. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 2) Here (with async bar function), if bar() takes some time to >>>>>>>>>>>> execute, >>>>>>>>>>> >>>>>>>>>>> Not quite, `await bar()` is afaict syntactic sugar for: >>>>>>>>>>> >>>>>>>>>>> bar { >>>>>>>>>>> printf("How are you ?"); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Where bar used to take a closure before, the compiler is just >>>>>>>>>>> making it for you. bar itself will be marked async and will handle >>>>>>>>>>> its asynchronous nature e.g. using dispatch or something else >>>>>>>>>>> entirely. >>>>>>>>>>> This has nothing to do with "time". >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If it's just syntactic sugar then how does this solve this issue >>>>>>>>>> mentioned in the concurrency manifesto ? >>>>>>>>>> "Beyond being syntactically inconvenient, completion handlers are >>>>>>>>>> problematic because their syntax suggests that they will be called >>>>>>>>>> on the current queue, but that is not always the case. For example, >>>>>>>>>> one of the top recommendations on Stack Overflow is to implement >>>>>>>>>> your own custom async operations with code like this (Objective-C >>>>>>>>>> syntax):" >>>>>>>>> >>>>>>>>> "where" things run is not addressed by async/await afaict, but Actors >>>>>>>>> or any library-level usage of it. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> So since async await don't have any impact on where things are >>>>>>>> executed, what would happen concretely with this code ? >>>>>>>> >>>>>>>> func slowFunction(_ input: [Int]) async -> [Int] { >>>>>>>> var results = [Int]() >>>>>>>> for element in input { >>>>>>>> results += [someLongComputation(with: element)] >>>>>>>> } >>>>>>>> return results >>>>>>>> } >>>>>>>> >>>>>>>> beginAsync { >>>>>>>> await slowFunction(manyElements) >>>>>>>> } >>>>>>>> >>>>>>>> I didn't specified anything about which queue/thread runs this code, >>>>>>>> so what would happen ? Would beginAsync block until slowFunction >>>>>>>> completes ? >>>>>>>> >>>>>>> >>>>>>> If I understand correctly, In real code you are not supposed to call >>>>>>> beginAsync. >>>>>>> It should be wrapped by high level frameworks. GCD may provide a method >>>>>>> that take an async lambda as parameter and dispatch it on a the global >>>>>>> concurrent queue. >>>>>>> Other library may provide entry point that run the code in a private >>>>>>> thread pool. >>>>>>> >>>>>>> This is just a primitive used to support coroutine, but does not define >>>>>>> how they are handled. >>>>>> >>>>>> >>>>>> Thank you everyone, I understand it better now, I still have some >>>>>> questions tough. >>>>>> Just to be sure that I am understanding this correctly, if you some >>>>>> async function and it suspends itself, then your current async function >>>>>> making this call will also suspend itself, right ? >>>>>> >>>>>> Also, I understand how suspendAsync will be used to warp current >>>>>> callback based functions into async/await friendly functions and in this >>>>>> case : >>>>>> func getStuff() async -> Stuff { >>>>>> return await suspendAsync { continuation in >>>>>> getStuff(completion: continuation) >>>>>> } >>>>>> } >>>>>> >>>>>> Here, I understand how the function controls where continuation is >>>>>> executed, but how would you write an API supporting async/await from >>>>>> scratch ? >>>>>> >>>>>> Say that I want to build an async function that downloads data, with >>>>>> libdispatch I could do : >>>>>> func dowloadSomething() { >>>>>> await someBackgroundQueue.asyncCorountine() >>>>>> // Here I would put my code for downloading data >>>>>> >>>>>> // But would I have to put anything after that to choose where to >>>>>> execute the continuation ? DispatchQueue.main.syncCorountine() maybe ? >>>>>> } >>>>> >>>>> The high level stuff is not designed yet, and how to specify the >>>>> continuation target queue/thread is not defined at this point. >>>>> >>>>> Your code will probably be something like >>>>> >>>>> Dispatch.startAync { >>>>> val stuff = await downloadStuff() >>>>> // do something with stuff once it is done. >>>>> } >>>> >>>> >>>> Do you mean that the API to execute the continuation back on its original >>>> thread ? (avoiding shared mutable state) >>> >>> I think you have to do something like this: >>> >>> func async doSomethingInBackground(callbackQueue: DispatchQueue) -> >>> SomeResult { >>> await someBackgroundQueue.asyncCorountine() >>> >>> // Here I would put my (potentially lengthy) background code. >>> >>> // Jump on the requested callback queue. >>> await callbackQueue.asyncCoroutine() >>> >>> // Return result (if any). >>> return result >>> } >>> >>> >>> Thomas >>> >> >> I hope this will be handled automatically the compiler tough ! > > > > > Did anyone started to sketch a design for how giving back control to the > calling queue will work ? > > Would it make any sense to limit asyncCorountine() to the scope of the > function where it gets called and implicitly "hop back" to the calling queue > so that no shared mutable state issues arise ?
No. Async methods are not require to be dispatched on a queue and all threads are not required to have a queue.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
