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 >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Sep 11, 2017, at 9:00 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swif

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> On Sep 4, 2017, at 12:18 PM, Pierre Habouzit > > wrote: >>> Something

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: >> >> https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts

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 >> swift: >> >> actor func foo() >> { >> NSLock *lock

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 break `foo` in > two p

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 >> mailto:swift-evolution@swift.org>>: >> >> >> Imagine you are maintaining a large codebase, and you come across this >> (intentionally abstract) code: >> >>

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 most useful, I’d argue that it

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 libdispatch.

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 process() -> Void) { >> loadWebResource("bigData.txt") {

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 careful here—the mere fact that a message returns `Void` doesn't mea

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 & swift-evo, > > (Given the alr

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 characters ('try await’ vs ‘await’)

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 imageReso

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") > let imageResource = load

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 dewarpAndCleanupImage(_ i : Image)

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 queue it runs on. I say this bec

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 c

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 GCD network code. Invariably my completion method sta

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

> 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 GCD network code. Invariably my completion method starts > with > > dispatch_async(queue_want_to_handle_this_on,) > > Replying on t

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 comple

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 >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Sep 4, 2017, at 10:36 AM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swi

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> On Sep 3, 2017, at 12:44 PM, Pierre Habouzit > > wrote: >>> My cur

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." > > Always? That is something

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" As a future extension yes,

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 great

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 this to a certain queue (in the thread(-pool?)

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 > > Basically: > • Use concurrent su

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 >> queues are just what you need with these possibili

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 > he means for these ac

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 they don’t block so >>> n

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 my >> background (simulation software on HPC)

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

> On Sep 4, 2017, at 7:53 AM, Gwendal Roué via swift-evolution > wrote: > > >> Le 4 sept. 2017 à 16:28, Wallacy via swift-evolution >> mailto:swift-evolution@swift.org>> a écrit : >> >> Hello, >> >> I have a little question about the actors. >> >> On WWDC 2012 Session 712 one of the most i

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. > >> On 3. Sep 2017, a

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 > > Basically: > • Use concurrent s

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”: dispatch_syn

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 > wrote: >> On Sep 2,

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

> On Sep 3, 2017, at 10:26 AM, Chris Lattner via swift-evolution > wrote: > > 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? > >

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 queues / tasks. >>> >>> It completely d

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 12:19 PM, Pierre Habouzit >

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 concurrent >>> queues / tasks. >> >> It complete

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 independent contexts.

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 >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Sep 2, 2017, at 14:15, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.org>>

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> My understanding is that GCD doesn’t currently scale to 1M concurrent queues >> / tasks. > > Hi Chris!

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 swift-evolution, so please forgive me if I

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 > > wrote: >>> >>> I fail at Finding the initial mai

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 don't undertsand or have questions about. >>

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 GCD is that it doesn'

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 insta

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 invocations of them - i.e a cycle

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 primitive you can build these

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 a

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 >> mailto:swift-evolution@swift.org>>: >> >> I understand what you’re saying, but I

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. When actors communicate with ea

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, and since you can get

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 await should cause the actor’s queue (or any queue) to be >>> susp

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 for asynchronous things. >> That’s how you

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 ti

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

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

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 >>> mailto:swift-evolution@swift.org>>: >>> Yes,

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 >> mailto:swift-evolution@swift.org>>: >> >>> >>> Yes, I think it is mandatory that we continue on the callers queue after an >>> `await ` on some actor method. >>> >>> If

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: >>> >>> On Aug 24, 2017, at 1:05 PM, Thomas via swift-evolution

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 method needs to be async then

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 >> queues manually if needed. >>

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> On 24 Aug 2017, at 21:48, Marc Schli

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 >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On 24 Aug 2017, at 21:48, Marc Schlichte >> > wrote: >>> >>> Yes, I think it is mandatory

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 queue after an >> `await ` on some actor method. >> >> If y

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 >> >: >>> >>> >>> On Aug 23, 2017, at 4:28

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Am 23.08.2017 um 12

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

> Am 24.08.2017 um 01:56 schrieb Adam Kemp : > > > >> On Aug 23, 2017, at 4:28 PM, Marc Schlichte via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> Am 23.08.2017 um 12:29 schrieb Thomas via swift-evolution >>> mailto:swift-evolution@swift.org>>: >>> >>> On 23

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

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 >> mailto: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 othe

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 loadWebResource("datapr

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 processes? It would seem to be the

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 character

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 lo

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 meaning of ! for logic erro

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 > // > } > printf("BigData Scheduled to load") >

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 // } printf(

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 >> interacting only with Swift code? If I were to write a

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 > mailto:swift-evolution@swift.org>>: >> On Aug 19, 2017, at 7:17 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> On Aug 19, 2017, at 8:14 A

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 approachabl

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 ‘ski

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> This looks fantastic. Can’t wait (heh) for async/await to land, and the >> Actors pattern looks really c

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 >> Actors pattern looks really compelling. >> >> One thought

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 if

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 structs and enums where value semantics is trivially >

  1   2   >