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

> On 18 Aug 2017, at 20:57, Chris Lattner wrote: > >> 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

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

> On 18 Aug 2017, at 21:11, Joe Groff wrote: > > >> On Aug 18, 2017, at 11:57 AM, Chris Lattner via swift-evolution >> wrote: >> >> I think that awaiting on the result of an actor method ends up being pretty >> similar (in terms of

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

> On 19 Aug 2017, at 07:30, Brent Royal-Gordon via swift-evolution > wrote: > >> On Aug 18, 2017, at 12:35 PM, Chris Lattner > > wrote: >> >>> (Also, I notice that a fire-and-forget message can be thought of as an

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

> On 18 Aug 2017, at 21:35, Chris Lattner via swift-evolution > wrote: > > Yeah, I think that actor methods deserve a bit of magic: > > - Their bodies should be implicitly async, so they can call async methods > without blocking their current queue or have to use

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

Maybe this will be handled more gracefully via the actor model. 1. if you're calling from an actor, you'd be called back on its internal queue. If you're calling from the 'main actor' (or just the main thread), you'd be called back on the main queue 2. you would just add a cancel() method to

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

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 23 Aug 2017, at 11:28, Thomas via swift-evolution > <swift-evolution@swift.org> 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 o

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

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

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

The compiler could rewrite this: print(await dataModel.getNumberOfEntries()) actor func getNumberOfEntries() -> Int { return theList.count } as this: dataModel.getNumberOfEntries(_internalQueue) { count in print(count) } actor func getNumberOfEntries(queue: DispatchQueue, handler: Int

Re: [swift-evolution] Question about async await

> On 25 Sep 2017, at 10:23, Trevör Anne Denise via swift-evolution > wrote: > > >> Le 24 sept. 2017 à 12:00, Jean-Daniel > > a écrit : >> >> >> >>> Le 23 sept. 2017 à 12:23, Trevör Anne Denise via

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

at 4:28 PM, Marc Schlichte via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> >>>> Am 23.08.2017 um 12:29 schrieb Thomas via swift-evolution >>>> <swift-evolution@swift.org <ma

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

> On 24 Aug 2017, at 22:05, Thomas via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On 24 Aug 2017, at 21:48, Marc Schlichte <marc.schlic...@googlemail.com >> <mailto:marc.schlic...@googlemail.com>> wrote: >> >&

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

> On 24 Aug 2017, at 23:47, Adam Kemp <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 Au

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

> 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

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

p <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: >>>> >&

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

> 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

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

> On 25 Aug 2017, at 09:04, Marc Schlichte <marc.schlic...@googlemail.com> > wrote: > > >> Am 24.08.2017 um 22:05 schrieb Thomas via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >> >>> >>

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

> On 25 Aug 2017, at 10:17, Thomas via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On 25 Aug 2017, at 09:04, Marc Schlichte <marc.schlic...@googlemail.com >> <mailto:marc.schlic...@googlemail.com>> wrote: >> >> >

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