This has been a long awaited topic so I'm really excited to see the conversation start! After reading the manifesto and the proposal there is one thing that keeps wondering in my head, and is making async implicitly throwing. It the common case it makes sense, but there is a part of the proposal that talks about "yields" and how the implementation is "coroutines" that can be used for other things not only for concurrent operations. In that case, wouldn't make more sense to keep throwing separated?
On Fri, Aug 18, 2017 at 2:17 PM, Thomas via swift-evolution <[email protected]> wrote: > I have been writing a lot of fully async code over the recent years (in objc) > and this all seems to fit well with what we're doing and looks like it would > alleviate a lot of the pain we have writing asyc code. > > # Extending the model through await > > I'm a bit worried about the mention of dispatch_sync() here (although it may > just be there to illustrate the deadlock possibility). I know the actor > runtime implementation is not yet defined, but just wanted to mention that > dispatch_sync() will lead to problems such as this annoying thing called > thread explosion. This is why we currently cannot use properties in our code > (getters would require us to call dispatch_sync() and we want to avoid that), > instead we are writing custom async getters/setters with callback blocks. > Having async property getters would be pretty awesome. > > Another thing: it is not clearly mentionned here that we're getting back on > the caller actor's queue after awaiting on another actor's async method. > > # Scalable Runtime > > About the problem of creating too many queues. This is something that has > annoyed me at this year's wwdc. It used to be back when the libdispatch was > introduced in 10.6 that we were told that queues are very cheap, we could > create thousands of them and not worry about threads, because the libdispatch > would do the right thing internally and adjust to the available hardware (the > number of threads would more or less match the number of cores in your > machine). Somehow this has changed, now we're being told we need to worry > about the threads behind the queues and not have too many of them. I'm not > sure if this is something inevitable due to the underlying reality of the > system but the way things were presented back then (think in term of queues, > don't worry about threads) was very compelling. > > # Entering and leaving async code > > Certainly seems like the beginAsync(), suspendAsync() primitives would be > useful outside of the stdlib. The Future<T> example makes use of > suspendAsync() to store the continuation block and call it later, other codes > would do just as well. > > Shouldn't this: > >> let imageTmp = await decodeImage(dataResource.get(), imageResource.get()) > > rather be: > >> let imageTmp = await decodeImage(await dataResource.get(), await >> imageResource.get()) > > > Thomas > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution -- Alejandro Martinez http://alejandromp.com _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
