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] [SE-0155][Discuss] The role of labels in enum case patterns

Apologies for rehashing this, but we seem to be going down that path… I am in the minority on this issue and have held my opinions because I thought that they would have served as simply a distraction and I was extremely busy at the time. That may have been a mistake on my part, because raising

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] 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] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 3, 2017, at 1:35 PM, Xiaodi Wu via swift-evolution > wrote: > > The desired behavior was the major topic of controversy during review; I’m > wary of revisiting this topic as we are essentially relitigating the proposal. > > To start off, the premise, if I

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] [Planning][Request] "constexpr" for Swift 5

Sorry for jumping late into this, about the topic of compile time execution, I raised it pretty much in the beginning of Swift being open sourced and it stills pops in my mind everytime I see Jonathan Blow use it in his language. So for my own curiosity, how feasible it is for Swift to do it with

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] 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] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 4, 2017, at 11:47 AM, T.J. Usiyan wrote: > > I wasn't arguing for a strictly parallel syntax. I was arguing against being > able to omit labels. I don't view those as strictly tied together. How are > they? Like Xiaodi I don’t think it would be productive to

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

I wasn't arguing for a strictly parallel syntax. I was arguing against being able to omit labels. I don't view those as strictly tied together. How are they? On Mon, Sep 4, 2017 at 12:38 PM, Matthew Johnson wrote: > > On Sep 4, 2017, at 10:52 AM, T.J. Usiyan via

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 4, 2017, at 10:52 AM, T.J. Usiyan via swift-evolution > wrote: > > While re-litigating has it's issues, I am for simplifying the rule and always > requiring the labels if they exist. This is similar to the change around > external labels. Yes, it is

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] [SE-0155][Discuss] The role of labels in enum case patterns

While re-litigating has it's issues, I am for simplifying the rule and always requiring the labels if they exist. This is similar to the change around external labels. Yes, it is slightly less convenient, but it removes a difficult to motivate caveat for beginners. On Sun, Sep 3, 2017 at 4:35 PM,

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] 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] 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] 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] Contextualizing async coroutines

Hello, > On 31. Aug 2017, at 20:35, Joe Groff via swift-evolution > wrote: > > # `onResume` hooks > > Relying on coroutine context alone still leaves responsibility wholly on > suspending APIs to pay attention to the coroutine context and schedule the >