Re: [swift-evolution] [Concurrency] A slightly different perspective

Thanks Pierre, When I answered, I was using my smartphone, so I copied the first code snippet from stackoverflow I found and remove some words. And in that case I'm happy to be a flawed example, and yet, its was most voted on stackoverflow. (the full exemple also does other mistakes). As

Re: [swift-evolution] [Concurrency] A slightly different perspective

Thanks for this Pierre! I think one of the main reasons I am proposing this is that this stuff is so easy to get wrong. I know I have gotten it wrong before in subtle ways which were really difficult to debug. By allowing the programmer to declare their intent, but not the implementation, we

Re: [swift-evolution] [Concurrency] A slightly different perspective

The first implementation I proposed before Wallacy suggested using dispatch_group_t does not involve any dispatching. It's possible that loadWebResource would dispatch in the background, but dispatching is not necessary either. For instance, loadWebResource could just be a wrapper for

Re: [swift-evolution] [Concurrency] A slightly different perspective

This doesn't work for priority tracking purposes, and is bad for locking domains too. What you really want here is: let groupLike : Dispatch.SomethingThatLooksLikeAGroupButDoesTracking() myNetworkingQueue().async(group: groupLike) { // loadWebResource } myNetworkingQueue().async(group:

Re: [swift-evolution] [Concurrency] A slightly different perspective

Yes, maybe in this way... Or using dispatch_group.. dispatch_group_t group = dispatch_group_create(); dispatch_group_async(group,dispatch_get_global_queue(0, 0), ^ { // loadWebResource}); dispatch_group_async(group,dispatch_get_global_queue(0, 0), ^ { // loadWebResource});

Re: [swift-evolution] [Concurrency] A slightly different perspective

> Le 4 sept. 2017 à 10:01, Wallacy via swift-evolution > a écrit : > > func processImageData1a() async -> > Image { > let dataResource = async loadWebResource("dataprofile.txt") > let imageResource = async loadWebResource("imagedata.dat") > > // ... other

Re: [swift-evolution] [Concurrency] A slightly different perspective

On Sep 3, 2017, at 5:01 PM, Jonathan Hull wrote: >> On Sep 3, 2017, at 9:04 AM, Chris Lattner via swift-evolution >> > wrote: >>> On Sep 3, 2017, at 4:00 AM, David Hart >>

Re: [swift-evolution] [Concurrency] A slightly different perspective

Tanks Jonathan, As you may already know, I am a great advocate of this feature. I will not repeat my explanations and examples that I gave in the other threads. But I think you got the idea right. Even without any kind of optimization, I believe there is a clear gain in this approach. But I

Re: [swift-evolution] [Concurrency] A slightly different perspective

I think we need to consider both the original proposal on its own, and also together with other potential proposals (including deferring ‘async’ and futures). We don’t need to have them fully spelled out, but I think the other proposals will help inform us where the sharp edges of await/async

Re: [swift-evolution] [Concurrency] A slightly different perspective

> On 3 Sep 2017, at 18:03, Chris Lattner wrote: > > >>> On Sep 3, 2017, at 4:00 AM, David Hart wrote: >>> >>> Please don’t read too much into the beginAsync API. It is merely a >>> strawman, and intended to be a low-level API that higher level

Re: [swift-evolution] [Concurrency] A slightly different perspective

Okay, that's an interesting proposal. I'm not qualified to judge how big of a win the compiler optimizations would be there; I'm a little skeptical, but I admit a lack of expertise there. It seems like it's not essential to the core 'async/await' proposal, though; it could be added later with

Re: [swift-evolution] [Concurrency] A slightly different perspective

> On Sep 3, 2017, at 7:35 PM, BJ Homer wrote: > > Jonathan, > > You've mentioned the desire to have 'async' defer calling 'await', but I > haven't seen a detailed design yet. Oh, we discussed it awhile back on a few other threads. I am happy to help write up a more

Re: [swift-evolution] [Concurrency] A slightly different perspective

Jonathan, You've mentioned the desire to have 'async' defer calling 'await', but I haven't seen a detailed design yet. For example, is the following code valid? let image = async fetchImage() let image2 = async fetchImage() let deferredThings = [image1, image2] If so, what is the type of

Re: [swift-evolution] [Concurrency] A slightly different perspective

> On Sep 3, 2017, at 9:04 AM, Chris Lattner via swift-evolution > wrote: >> On Sep 3, 2017, at 4:00 AM, David Hart > > wrote: >>> Please don’t read too much into the beginAsync API. It is merely a >>> strawman, and

Re: [swift-evolution] [Concurrency] A slightly different perspective

> On Sep 3, 2017, at 4:00 AM, David Hart wrote: > >> Please don’t read too much into the beginAsync API. It is merely a >> strawman, and intended to be a low-level API that higher level abstractions >> (like a decent futures API) can be built on top of. I think it is

Re: [swift-evolution] [Concurrency] A slightly different perspective

> On 2 Sep 2017, at 20:24, Chris Lattner via swift-evolution > wrote: > > On Aug 31, 2017, at 3:04 PM, Nathan Gray via swift-evolution > wrote: >> I've been following the conversations around Chris Lattner's intriguing >> async/await

Re: [swift-evolution] [Concurrency] A slightly different perspective

On Aug 31, 2017, at 3:04 PM, Nathan Gray via swift-evolution wrote: > I've been following the conversations around Chris Lattner's intriguing > async/await proposal and would like to offer my own take. I feel that the > proposal as written is almost perfect. My

Re: [swift-evolution] [Concurrency] A slightly different perspective

Sent from my iPad > On Sep 1, 2017, at 12:44 AM, Marc Schlichte > wrote: > > No, > > as I see it, async / await without actors should behave the same way as if > you pass continuations instead - especially if we auto convert CPS style > functions into

Re: [swift-evolution] [Concurrency] A slightly different perspective

@swift.orgBetreff: Re: [swift-evolution] [Concurrency] A slightly different perspective On Aug 31, 2017, at 3:31 PM, Marc Schlichte <marc.schlic...@googlemail.com> wrote:Am 01.09.2017 um 00:04 schrieb Nathan Gray via swift-evolution <swift-evolution@swift.org>:1. Fixing "queue

Re: [swift-evolution] [Concurrency] A slightly different perspective

> On Aug 31, 2017, at 3:31 PM, Marc Schlichte > wrote: > > >> Am 01.09.2017 um 00:04 schrieb Nathan Gray via swift-evolution >> : >> >> 1. Fixing "queue confusion" *must* be part of this proposal. The key bit of >> "magic" offered

Re: [swift-evolution] [Concurrency] A slightly different perspective

That's the second time today somebody has responded to one of my messages before I posted it. Glitch in the Matrix? I'll post a more detailed response later on but the tl;dr is that I think you're right on target. My first impression is that both of my major concerns could be solved and it

Re: [swift-evolution] [Concurrency] A slightly different perspective

> Am 01.09.2017 um 00:04 schrieb Nathan Gray via swift-evolution > : > > 1. Fixing "queue confusion" *must* be part of this proposal. The key bit of > "magic" offered by async/await over continuation passing is that you're > working in a single scope. A single

[swift-evolution] [Concurrency] A slightly different perspective

I've been following the conversations around Chris Lattner's intriguing async/await proposal and would like to offer my own take. I feel that the proposal as written is almost perfect. My suggestions for improving it are not highly original -- I think they have all come up already -- but I'd like