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

> On Sep 12, 2017, at 12:31 PM, John McCall via swift-evolution > wrote: > >> >> On Sep 12, 2017, at 2:19 AM, Pierre Habouzit via swift-evolution >> > wrote: >> >>> On Sep 11, 2017, at 9:00 PM, Chris

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

> On Sep 12, 2017, at 2:19 AM, Pierre Habouzit via swift-evolution > wrote: > >> On Sep 11, 2017, at 9:00 PM, Chris Lattner via swift-evolution >> > wrote: >> >> On Sep 4, 2017, at 12:18 PM, Pierre

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

> On 11 Sep 2017, at 10:04 pm, Adam Kemp via swift-evolution > wrote: > > > >> On Sep 11, 2017, at 1:15 PM, Kenny Leung via swift-evolution >> wrote: >> >> I found a decent description about async/await here: >> >>

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

> On Sep 11, 2017, at 9:00 PM, Chris Lattner via swift-evolution > wrote: > > On Sep 4, 2017, at 12:18 PM, Pierre Habouzit > wrote: >> Something else I realized, is that this code is fundamentally broken in >>

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

On Sep 4, 2017, at 12:18 PM, Pierre Habouzit wrote: > Something else I realized, is that this code is fundamentally broken in swift: > > actor func foo() > { > NSLock *lock = NSLock(); > lock.lock(); > > let compute = await someCompute(); <--- this will really

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

> On Sep 11, 2017, at 4:19 PM, Marc Schlichte > wrote: > > >> Am 07.09.2017 um 07:05 schrieb Chris Lattner via swift-evolution >> >: >> >> >> Imagine you are maintaining a large codebase, and you

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

> Am 07.09.2017 um 07:05 schrieb Chris Lattner via swift-evolution > : > > > Imagine you are maintaining a large codebase, and you come across this > (intentionally abstract) code: > > foo() > await bar() > baz() > > Regardless of what is the

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

> On Sep 11, 2017, at 1:15 PM, Kenny Leung via swift-evolution > wrote: > > I found a decent description about async/await here: > > https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/ > >

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

I found a decent description about async/await here: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/ So it’s much more like runloop based callbacks in Foundation that

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

> Am 21.08.2017 um 22:32 schrieb Brent Royal-Gordon via swift-evolution > : > >> On Aug 21, 2017, at 12:41 PM, Wallacy via swift-evolution >> wrote: >> >> Based on these same concerns, how to do this using async/await ? >> >> func

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

If I understand correctly this queue/thread hopping problem arises because we do not want `await` to block. If `await` would block we would trivially stay in the same thread/on the same queue. Actually I think that the mental model and the semantics should work as if `await` did block. Anything

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

> Am 20.08.2017 um 04:38 schrieb Thomas via swift-evolution > : > > >>> On 20 Aug 2017, at 03:36, Brent Royal-Gordon wrote: >>> On Aug 19, 2017, at 2:25 AM, Thomas wrote: I think we need to be a little

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

> On 11 Sep 2017, at 00:10, Howard Lovatt via swift-evolution > wrote: > > Not really certain what async/await adds, using this library (note self > promotion) which is built on top of GCD: > > https://github.com/hlovatt/Concurrency-Utilities >

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

Not really certain what async/await adds, using this library (note self promotion) which is built on top of GCD: https://github.com/hlovatt/Concurrency-Utilities You can write: func doit() { AsynchronousFuture { // Executes in background and therefore does not block main

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

First off, I’m still catching up with all those (very welcome :-) threads about concurrency, so bear with me if I’m commenting on topics that have been settled in the meantime. > Am 18.08.2017 um 17:13 schrieb Johannes Weiß via swift-evolution > : > > Hi Chris &

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

> Am 21.08.2017 um 22:09 schrieb Karim Nassar via swift-evolution > : > > Thought about it in more depth, and I’m now firmly in the camp of: > ‘throws’/‘try' and ‘async’/‘await' should be orthogonal features. I think the > slight call-site reduction in typed

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

This is the only part of the proposal that i can't concur! ^async^ at call side solve this nicely! And Pierre also showed how common people are doing it wrong! And will make this wrong using Futures too. func doit() async { let dataResource = async loadWebResource("dataprofile.txt”) let

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

> On 10 Sep 2017, at 00:40, Kenny Leung via swift-evolution > wrote: > > Then isn’t the example functionally equivalent to: > > func doit() { > DispatchQueue.global().async { > let dataResource = loadWebResource("dataprofile.txt") >

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

Then isn’t the example functionally equivalent to: func doit() { DispatchQueue.global().async { let dataResource = loadWebResource("dataprofile.txt") let imageResource = loadWebResource("imagedata.dat") let imageTmp = decodeImage(dataResource,

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

> On 8 Sep 2017, at 20:34, Kenny Leung via swift-evolution > wrote: > > Hi All. > > A point of clarification in this example: > > func loadWebResource(_ path: String) async -> Resource > func decodeImage(_ r1: Resource, _ r2: Resource) async -> Image > func

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

Hi All. A point of clarification in this example: func loadWebResource(_ path: String) async -> Resource func decodeImage(_ r1: Resource, _ r2: Resource) async -> Image func dewarpAndCleanupImage(_ i : Image) async -> Image func processImageData1() async -> Image { let dataResource = await

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

> On Sep 7, 2017, at 1:04 AM, Howard Lovatt via swift-evolution > wrote: > > I would argue that given: > > foo() > await bar() > baz() > > That foo and baz should run on the same queue (using queue in the GCD sense) > but bar should determine which

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

I would argue that given: foo() await bar() baz() That foo and baz should run on the same queue (using queue in the GCD sense) but bar should determine which queue it runs on. I say this because: 1. foo and baz are running synchronously with respect to each other (though they

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

> On 7 Sep 2017, at 07:05, Chris Lattner via swift-evolution > wrote: > > >> On Sep 5, 2017, at 7:31 PM, Eagle Offshore via swift-evolution >> wrote: >> >> OK, I've been watching this thing for a couple weeks. >> >> I've done a lot of

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

OK, I've been watching this thing for a couple weeks. I've done a lot of GCD network code. Invariably my completion method starts with dispatch_async(queue_want_to_handle_this_on,) Replying on the same queue would be nice I guess, only often all I need to do is update the UI in the

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

> On Sep 5, 2017, at 5:29 PM, Elliott Harris via swift-evolution > wrote: > >> >> On Sep 4, 2017, at 11:40 AM, Pierre Habouzit via swift-evolution >> > wrote: >> >>> On Sep 4, 2017, at 10:36 AM, Chris

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

> On Sep 4, 2017, at 11:40 AM, Pierre Habouzit via swift-evolution > wrote: > >> On Sep 4, 2017, at 10:36 AM, Chris Lattner via swift-evolution >> > wrote: >> >> On Sep 3, 2017, at 12:44 PM, Pierre

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

Fair enough! Tranks! Em ter, 5 de set de 2017 às 13:48, Pierre Habouzit escreveu: > On Sep 5, 2017, at 9:29 AM, Wallacy via swift-evolution < > swift-evolution@swift.org> wrote: > > "Actors are serial and exclusive, so this concurrent queue thing is not > relevant." > >

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

> On Sep 5, 2017, at 9:29 AM, Wallacy via swift-evolution > wrote: > > "Actors are serial and exclusive, so this concurrent queue thing is not > relevant." > > Always? That is something i can't understand. The proposal actually cites the > "Intra-actor concurrency"

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

"Actors are serial and exclusive, so this concurrent queue thing is not relevant." Always? That is something i can't understand. The proposal actually cites the "Intra-actor concurrency" "Also, int he QoS world, using reader writer locks or private concurrent queues this way is not terribly

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

-Pierre > On Sep 4, 2017, at 9:10 AM, Chris Lattner via swift-evolution > wrote: > > >> On Sep 4, 2017, at 9:05 AM, Jean-Daniel > > wrote: >> Sometimes, I’d probably make sense (or even be required to fix

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

> On Sep 4, 2017, at 7:27 AM, Wallacy via swift-evolution > wrote: > > Hello, > > I have a little question about the actors. > > On WWDC 2012 Session 712 one of the most important tips (for me at least) > was: Improve Performance with Reader-Writer Access > >

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

> On Sep 4, 2017, at 10:36 AM, Chris Lattner via swift-evolution > wrote: > > On Sep 3, 2017, at 12:44 PM, Pierre Habouzit > wrote: >> My currently not very well formed opinion on this subject is that GCD >>

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

On Sep 3, 2017, at 12:44 PM, Pierre Habouzit wrote: > My currently not very well formed opinion on this subject is that GCD > queues are just what you need with these possibilities: > - this Actor queue can be targeted to other queues by the developer when >

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

> On Sep 4, 2017, at 9:05 AM, Jean-Daniel wrote: > >>> Sometimes, I’d probably make sense (or even be required to fix this to a >>> certain queue (in the thread(-pool?) sense), but at others it may just make >>> sense to execute the messages in-place by the sender if

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

> Le 4 sept. 2017 à 17:54, Chris Lattner via swift-evolution > a écrit : > > On Sep 4, 2017, at 4:19 AM, Daniel Vollmer > wrote: >> >> Hello, >> >> first off, I’m following this discussion with great interest, even though

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

On Sep 4, 2017, at 4:19 AM, Daniel Vollmer wrote: > > Hello, > > first off, I’m following this discussion with great interest, even though my > background (simulation software on HPC) has a different focus than the > “usual” paradigms Swift seeks to (primarily) address. > >>

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

> Le 4 sept. 2017 à 16:28, Wallacy via swift-evolution > a écrit : > > Hello, > > I have a little question about the actors. > > On WWDC 2012 Session 712 one of the most important tips (for me at least) > was: Improve Performance with Reader-Writer Access > >

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

Hello, I have a little question about the actors. On WWDC 2012 Session 712 one of the most important tips (for me at least) was: Improve Performance with Reader-Writer Access Basically: • Use concurrent subsystem queue: DISPATCH_QUEUE_CONCURRENT • Use synchronous concurrent “reads”:

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

Hello, first off, I’m following this discussion with great interest, even though my background (simulation software on HPC) has a different focus than the “usual” paradigms Swift seeks to (primarily) address. > On 3. Sep 2017, at 19:26, Chris Lattner via swift-evolution >

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

On Sep 2, 2017, at 11:09 PM, Pierre Habouzit wrote: >> On Sep 2, 2017, at 12:19 PM, Pierre Habouzit > > wrote: > What do you mean by this? My understanding is that GCD doesn’t currently scale to 1M concurrent

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

[Sorry I hit send too fast, let me fix two spots I didn't correct] > On Sep 2, 2017, at 11:09 PM, Pierre Habouzit wrote: > > > -Pierre > >> On Sep 2, 2017, at 9:59 PM, Chris Lattner > > wrote: >> >> On Sep 2, 2017, at

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

-Pierre > On Sep 2, 2017, at 9:59 PM, Chris Lattner wrote: > > On Sep 2, 2017, at 12:19 PM, Pierre Habouzit > wrote: What do you mean by this? >>> >>> My understanding is that GCD doesn’t currently scale to 1M

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

On Sep 2, 2017, at 12:19 PM, Pierre Habouzit wrote: >>> What do you mean by this? >> >> My understanding is that GCD doesn’t currently scale to 1M concurrent queues >> / tasks. > > It completely does provided these 1M queues / tasks are organized on several > well known

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

> On Sep 2, 2017, at 2:19 PM, Charles Srstka via swift-evolution > wrote: > >> On Sep 2, 2017, at 4:05 PM, David Zarzycki via swift-evolution >> > wrote: >> >>> On Sep 2, 2017, at 14:15, Chris Lattner via

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

> On Sep 2, 2017, at 4:05 PM, David Zarzycki via swift-evolution > wrote: > >> On Sep 2, 2017, at 14:15, Chris Lattner via swift-evolution >> > wrote: >> >> My understanding is that GCD doesn’t currently

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

> On Sep 2, 2017, at 14:15, Chris Lattner via swift-evolution > wrote: > > My understanding is that GCD doesn’t currently scale to 1M concurrent queues > / tasks. Hi Chris! [As a preface, I’ve only read a few of these concurrency related emails on

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

> On Sep 2, 2017, at 3:19 PM, Pierre Habouzit via swift-evolution > wrote: > >> On Sep 2, 2017, at 11:15 AM, Chris Lattner > > wrote: >> >> On Aug 31, 2017, at 7:24 PM, Pierre Habouzit >

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

> On Sep 2, 2017, at 11:15 AM, Chris Lattner wrote: > > On Aug 31, 2017, at 7:24 PM, Pierre Habouzit > wrote: >> >> I fail at Finding the initial mail and am quite late to the party of >> commenters, but there are parts I

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

On Aug 31, 2017, at 7:24 PM, Pierre Habouzit wrote: > > I fail at Finding the initial mail and am quite late to the party of > commenters, but there are parts I don't undertsand or have questions about. > > Scalable Runtime > > [...] > > The one problem I anticipate with

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

I fail at Finding the initial mail and am quite late to the party of commenters, but there are parts I don't undertsand or have questions about. Scalable Runtime [...] The one problem I anticipate with GCD is that it doesn't scale well enough: server developers in particular will want to

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

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

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

> Am 26.08.2017 um 02:03 schrieb Adam Kemp via swift-evolution > : > > 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

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

> On Aug 25, 2017, at 10:12 PM, Howard Lovatt via swift-evolution > wrote: > > I think we would be better off with a future type rather than async/await > since they can offer timeout, cancel, and control over which thread execution > occurs on. async/await is a

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

I think we would be better off with a future type rather than async/await since they can offer timeout, cancel, and control over which thread execution occurs on. -- Howard. On 26 August 2017 at 00:06, Cavelle Benjamin via swift-evolution < swift-evolution@swift.org> wrote: > Disclaimer: not

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

I’m not sure I understand. What is the connection between references and deadlocks? > On Aug 25, 2017, at 1:07 PM, Marc Schlichte > wrote: > > >> Am 25.08.2017 um 19:08 schrieb Adam Kemp via swift-evolution >>

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

> Am 25.08.2017 um 19:08 schrieb Adam Kemp via swift-evolution > : > > 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.

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

> On Aug 25, 2017, at 9:54 AM, Thomas wrote: > > I'd tend to think non-FIFO actor messaging will cause more trouble than > potential deadlocks. I'm re-reading the proposal and it seems to go this way > as well: > > "An await on an actor method suspends the current task,

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

> On 25 Aug 2017, at 18:30, Adam Kemp wrote: > > > >> On Aug 25, 2017, at 1:14 AM, Thomas > > wrote: >>> On 25 Aug 2017, at 01:15, Adam Kemp >> > wrote: >>> I don’t think

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

Cancellation and time out can be built into futures, and async/await can interact with futures. I don’t think we need async/await itself to support either of those. Just as a real-world example, C#’s async/await feature doesn’t have built-in timeout or cancellation support, but it’s still easy

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

> On Aug 25, 2017, at 1:14 AM, Thomas wrote: >> On 25 Aug 2017, at 01:15, Adam Kemp > > wrote: >> I don’t think await should cause the actor’s queue (or any queue) to be >> suspended. Actor methods should not block waiting

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

Disclaimer: not an expert Question I didn’t see any where the async is required to time out after a certain time frame. I would think that we would want to specify both on the function declaration side as a default and on the function call side as a customization. That being said, the return

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

> On 25 Aug 2017, at 10:14, Thomas via swift-evolution > wrote: > > >> On 25 Aug 2017, at 01:15, Adam Kemp > > wrote: >> >> >> >>> On Aug 24, 2017, at 3:15 PM, Thomas >>

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

> On 25 Aug 2017, at 10:14, Thomas via swift-evolution > wrote: > > >> On 25 Aug 2017, at 01:15, Adam Kemp > > wrote: >> >> >> >>> On Aug 24, 2017, at 3:15 PM, Thomas >>

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

> On 25 Aug 2017, at 10:17, Thomas via swift-evolution > wrote: > >> >> On 25 Aug 2017, at 09:04, Marc Schlichte > > wrote: >> >> >>> Am 24.08.2017 um 22:05 schrieb Thomas via swift-evolution

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

> On 25 Aug 2017, at 09:04, Marc Schlichte > wrote: > > >> Am 24.08.2017 um 22:05 schrieb Thomas via swift-evolution >> >: >> >>> >>> Yes, I think it is mandatory that we continue on the callers

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

> On 25 Aug 2017, at 01:15, Adam Kemp wrote: > > > >> On Aug 24, 2017, at 3:15 PM, Thomas > > wrote: >> >> >>> On 24 Aug 2017, at 23:47, Adam Kemp >> > wrote: >>> >>>

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

> Am 25.08.2017 um 01:15 schrieb Adam Kemp via swift-evolution > : > > 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

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

> Am 24.08.2017 um 22:05 schrieb Thomas via swift-evolution > : > >> >> 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 >>

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

> On Aug 24, 2017, at 3:15 PM, Thomas wrote: > > >> On 24 Aug 2017, at 23:47, Adam Kemp > > wrote: >> >> >>> On Aug 24, 2017, at 1:05 PM, Thomas via swift-evolution >>>

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

> On 24 Aug 2017, at 23:47, Adam Kemp wrote: > > >> On Aug 24, 2017, at 1:05 PM, Thomas via swift-evolution >> > wrote: >> >>> >>> On 24 Aug 2017, at 21:48, Marc Schlichte >>

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

> On Aug 24, 2017, at 1:05 PM, Thomas via swift-evolution > wrote: > >> >> On 24 Aug 2017, at 21:48, Marc Schlichte > > wrote: >> >> Yes, I think it is mandatory that we continue on the callers

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

Re: Chris Lattner recently commented in that the prototype could use support. In one of the CppCon videos, Gor Nishanov said that C++ coroutines

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

> On 24 Aug 2017, at 22:05, Thomas via swift-evolution > wrote: > >> >> On 24 Aug 2017, at 21:48, Marc Schlichte > > wrote: >> >> >>> Am 24.08.2017 um 01:56 schrieb Adam Kemp

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

> On 24 Aug 2017, at 21:48, Marc Schlichte > wrote: > > >> Am 24.08.2017 um 01:56 schrieb Adam Kemp > >: >> >> >> >>> On Aug 23, 2017, at 4:28 PM, Marc Schlichte via swift-evolution >>>

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

> On Aug 23, 2017, at 4:28 PM, Marc Schlichte via swift-evolution > wrote: > > >> Am 23.08.2017 um 12:29 schrieb Thomas via swift-evolution >> >: >> >> >>> On 23 Aug 2017, at 11:28, Thomas via

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

> Am 23.08.2017 um 12:29 schrieb Thomas via swift-evolution > : > > >> On 23 Aug 2017, at 11:28, Thomas via swift-evolution >> > wrote: >> >> 1. What happens to the actor's queue when the body of a (non

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

Hi Chris, This looks amazing(!) … I am really looking forward to the end result whatever that may be, because I know it will be awesome. Im really excited and a lot raced though my mind while I read it... ——— Part 1: Async/await let dataResource = await

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

> On 23 Aug 2017, at 11:28, Thomas via swift-evolution > wrote: > > 1. What happens to the actor's queue when the body of a (non void-returning) > actor method awaits away on some other actor? Does it suspend the queue to > prevent other messages from being

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

Just wanted to sum up my actors interrogation here: 1. What happens to the actor's queue when the body of a (non void-returning) actor method awaits away on some other actor? Does it suspend the queue to prevent other messages from being processes? It would seem to be the expected behavior but

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

On Mon, Aug 21, 2017 at 4:09 PM, Karim Nassar via swift-evolution < swift-evolution@swift.org> wrote: > Thought about it in more depth, and I’m now firmly in the camp of: > ‘throws’/‘try' and ‘async’/‘await' should be orthogonal features. I think > the slight call-site reduction in typed

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

Alternatively, until futures are a thing, you can call `beginAsync` twice to start to async tasks: func process() -> Void { beginAsync { let dataResource = await loadWebResource("bigData.txt") // } print("BigData Scheduled to

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

>> On Aug 21, 2017, at 1:56 PM, John McCall wrote: >> >> Personally, I think these sources of confusion are a good reason to keep the >> feature separate. >> >> The idea of using await! to block a thread is interesting but, as you say, >> does not fit with the general

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

> On Aug 21, 2017, at 12:41 PM, Wallacy via swift-evolution > wrote: > > Based on these same concerns, how to do this using async/await ? > > func process() -> Void) { > loadWebResource("bigData.txt") { dataResource in > // > } >

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

Thought about it in more depth, and I’m now firmly in the camp of: ‘throws’/‘try' and ‘async’/‘await' should be orthogonal features. I think the slight call-site reduction in typed characters ('try await’ vs ‘await’) is heavily outweighed by the loss of clarity on all the edge cases. —Karim >

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

Based on these same concerns, how to do this using async/await ? func process() -> Void) { loadWebResource("bigData.txt") { dataResource in // } printf("BigData Scheduled to load") loadWebResource("smallData.txt") { dataResource in // }

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

> On Aug 18, 2017, at 8:38 PM, Chris Lattner > wrote: > > On Aug 18, 2017, at 2:09 PM, Adam Kemp > wrote: >> Maybe I’m still missing something, but how does this help when you are >>

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

> On Aug 20, 2017, at 3:56 PM, Yuta Koshizawa wrote: > > 2017-08-21 2:20 GMT+09:00 John McCall via swift-evolution > >: >> On Aug 19, 2017, at 7:17 PM, Chris Lattner via swift-evolution >>

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

I have read over the proposal and already asked a few questions ahead of the email chain and I have some follow up points that are perhaps worth consideration. First off, I think that async/await is a great concept! From personally using a similar concept in C#, I think it can be an

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

2017-08-21 2:20 GMT+09:00 John McCall via swift-evolution < swift-evolution@swift.org>: > On Aug 19, 2017, at 7:17 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > On Aug 19, 2017, at 8:14 AM, Karim Nassar via swift-evolution < > swift-evolution@swift.org> wrote: >

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

Howdy, It’s good to have a formal, language supported way to manage these aspects of concurrency. In particular, I like that it establishes the asynchronously provided values into the surrounding scope, like guard. This helps me write a clean sequence of calls with access to values which

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

> On Aug 19, 2017, at 7:17 PM, Chris Lattner via swift-evolution > wrote: >> On Aug 19, 2017, at 8:14 AM, Karim Nassar via swift-evolution >> > wrote: >> >> This looks fantastic. Can’t wait (heh) for

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

> what's important is that the code may pause for a while during a given > expression and run other stuff in the meantime. I think that’s what `yield` actually means. In you sentence there is nothing about (a)waiting, only about pausing and ‘yielding’ the cpu time to ‘run other stuff’. -g.

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

> On 20 Aug 2017, at 01:17, Chris Lattner via swift-evolution > wrote: > > >> On Aug 19, 2017, at 8:14 AM, Karim Nassar via swift-evolution >> wrote: >> >> This looks fantastic. Can’t wait (heh) for async/await to land, and the >>

Re: [swift-evolution] [Concurrency] async/await + actors: cancellation

Hi Joe, Thanks for the answers so far! Abrupt cancellation is indeed not a good idea, but I wander if it is possible on every place where “await” is being used, to let the compiler generate code which handles cancellation, assuming that can be cheap enough (and I am not qualified to judge

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

Sent from my iPad > On Aug 19, 2017, at 9:33 PM, Brent Royal-Gordon > wrote: > >> On Aug 19, 2017, at 7:41 AM, Matthew Johnson wrote: >> >> Regardless of which approach we take, it feels like something that needs to >> be implicit for

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

> On Aug 19, 2017, at 1:29 PM, Michel Fortin via swift-evolution > wrote: > > I'm not actually that interested in the meaning of value semantics here. I'm > debating the appropriateness of determining whether something can be done in > another thread based on the

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

> On 20 Aug 2017, at 03:36, Brent Royal-Gordon wrote: > >> On Aug 19, 2017, at 2:25 AM, Thomas > > wrote: >> >>> I think we need to be a little careful here—the mere fact that a message >>> returns `Void` doesn't mean

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

> On Aug 19, 2017, at 7:41 AM, Matthew Johnson wrote: > > Regardless of which approach we take, it feels like something that needs to > be implicit for structs and enums where value semantics is trivially provable > by way of transitivity. When that is not the case we

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

> On Aug 19, 2017, at 3:23 AM, Georgios Moschovitis via swift-evolution > wrote: > > I am wondering, am I the only one that *strongly* prefers `yield` over > `await`? > > Superficially, `await` seems like the standard term, but given the fact that > the proposal is

  1   2   >