Post APZSP29eHYgr5wutZg by mattiem@mastodon.social
(DIR) More posts by mattiem@mastodon.social
(DIR) Post #APZSOzTOFhhOmJ87Qe by mattiem@mastodon.social
2022-11-09T14:29:42Z
0 likes, 0 repeats
My little library of Swift concurrency additions continues to be immensely useful to myself, and others which is super cool!Aside from the basically-necessary FIFO task queue, now it also includes Async(Throwing)Subject, which makes it much easier to make an AsyncSequence from non-async code.https://github.com/chimeHQ/ConcurrencyPlus
(DIR) Post #APZSP04c1JTOdkXqRk by krzyzanowskim@mastodon.social
2022-11-10T14:38:26Z
0 likes, 0 repeats
@mattiem while on that, I noticed this https://github.com/mredig/AsyncConcurrentQueue approach to FIFO task queue. just FYI
(DIR) Post #APZSP0k5X6eMiNwy5w by mattiem@mastodon.social
2022-11-10T14:54:05Z
0 likes, 0 repeats
@krzyzanowskim ah interesting! A little different but very cool!
(DIR) Post #APZSP1CnoLcQ9RNtqq by kyle@computersocial.club
2022-11-10T22:46:24Z
0 likes, 0 repeats
@mattiem @krzyzanowskim I have a nearly identical implementation of what Marcin linked but I don’t think it works for more than 1 concurrent task. The Queue is defined as an Actor which means, I believe, it can only execute 1 non-detached task at a time. Is my understanding correct? It does work as a serial FIFO queue for tasks, though.
(DIR) Post #APZSP29eHYgr5wutZg by mattiem@mastodon.social
2022-11-10T22:47:43Z
0 likes, 0 repeats
@kyle @krzyzanowskim not enough info to be sure, but in general no, actors are not serialized and could definitely do more than one at a time
(DIR) Post #APZSP2ciXTwUY6W6sq by krzyzanowskim@mastodon.social
2022-11-10T23:07:19Z
0 likes, 0 repeats
@mattiem @kyle no. wait. is this true? where was recent the discussion around that. @cocoaphony do you recall?
(DIR) Post #APZSP37Ci8KS4emSP2 by cocoaphony@mastodon.social
2022-11-10T23:20:26Z
0 likes, 0 repeats
@krzyzanowskim @mattiem @kyle An actor will only do one thing at a time until it comes to an await. At that point, it can re-enter and start another task. So it’s not good to think of it as a serial queue if there are any async methods (and there always are).
(DIR) Post #APZSP3WNCYShKiYYdM by helge@mastodon.social
2022-11-10T23:40:58Z
0 likes, 0 repeats
@cocoaphony @krzyzanowskim @mattiem @kyle Which is pretty weird almost to the point of making an "Swift actor" as an abstract concept being useless, isn't it? An actor shouldn't be reentrant?
(DIR) Post #APZSP41ZKZPotT9TG4 by mattiem@mastodon.social
2022-11-10T23:43:43Z
0 likes, 0 repeats
@helge @cocoaphony @krzyzanowskim @kyle definitely not useless, but also not a magic solution to all (many) synchronization needs.
(DIR) Post #APZSP4Oxva8A4269j6 by helge@mastodon.social
2022-11-10T23:45:56Z
0 likes, 0 repeats
@mattiem @cocoaphony @krzyzanowskim @kyle No one ever asks that it is a magic solution to synchronization needs, just that it actually acts like an actor (what a beauty).
(DIR) Post #APZSP4xLrjdVmgBcK8 by helge@mastodon.social
2022-11-10T23:48:01Z
0 likes, 0 repeats
@mattiem @cocoaphony @krzyzanowskim @kyle BTW: the real explanation for that weird behavior is AFAIK guaranteed forward progress. Not sure it warrants that weirdness though.
(DIR) Post #APZSP5QQ7et9EpmpdI by krzyzanowskim@mastodon.social
2022-11-10T23:57:24Z
0 likes, 0 repeats
@mattiem @helge @cocoaphony @kyle I don't understand swift actors. again. why it has to be so unclear
(DIR) Post #APZSP5y66RpKvHXj7o by mattiem@mastodon.social
2022-11-11T00:02:48Z
0 likes, 0 repeats
@krzyzanowskim @helge @cocoaphony @kyle sorry if that comment sounded weird. I’ve never used actors in any other environment, so I’m unsure how they stack up.I find swift concurrency to be difficult to use right. Its subtle and often deceiving. I’ve introduced lots of races using it.
(DIR) Post #APZSP6UMAVdCXKdUPI by krzyzanowskim@mastodon.social
2022-11-11T00:14:07Z
0 likes, 0 repeats
@helge @cocoaphony @mattiem @kyle which is the opposite what it was designed for? well
(DIR) Post #APZSP6wMUO25wBjr3g by krzyzanowskim@mastodon.social
2022-11-11T00:20:24Z
0 likes, 0 repeats
@helge @kyle @cocoaphony @mattiem I need "Swift Actor for Dummies" where I can ask all the stupid questions
(DIR) Post #APZSP7XEHJWVmWzIWW by jjoelson@mastodon.social
2022-11-11T01:47:10Z
0 likes, 0 repeats
@mattiem @kyle @krzyzanowskim @helge @cocoaphony AFAICT Actors are mostly about low-level memory safety i.e. making sure that two threads don’t use the same memory at the same time.It doesn’t do anything to make async *logic* easier; it just helps you avoid that situation where you forgot to dispatch to the main queue.
(DIR) Post #APZSP84YHQB7RsZuSm by cocoaphony@mastodon.social
2022-11-11T02:32:56Z
0 likes, 0 repeats
@jjoelson @mattiem @kyle @krzyzanowskim @helge I agree. They’re not really like actors in other languages (which are pretty easy to build with an AsyncChannel and a Task in Swift).I‘ve designed with (proper) actors in Akka, Go, and Rust, and I like them, but the fact that they *are* serial has always eventually led to deadlocks (Go has a very powerful runtime deadlock detector to try to help with this). So serial actors have their own problems. But it is a weird choice of term for Swift.
(DIR) Post #APZSP8UQjCsWk8gZnc by matt@oliphaunt.social
2022-11-11T22:57:52Z
0 likes, 0 repeats
@cocoaphony @jjoelson @mattiem @kyle @krzyzanowskim @helgeHm, I'm not sure I'd say Swift actors aren't "proper"; IIRC they simply have an additional mechanism that lets you await a direct reply instead of splitting your work into multiple message handlers to coordinate the replies from your coactors. Every `await` call is a spot you could cut your method short and implement a separate replyHandler method, with your coactors messaging back instead of returning.
(DIR) Post #APZSP8v18M964b7oEy by cocoaphony@mastodon.social
2022-11-11T23:11:33Z
0 likes, 0 repeats
@matt @jjoelson @mattiem @kyle @krzyzanowskim @helge It's actually a pretty good argument. The thing that's missing is Akka's `?` syntax that would let you *not* "cut your method short." But in practice (though I never shipped any production Akka), when I worked in it I often saw a push away from `?`, favoring...Swift-style reentrancy with either Become or keeping track of expected responses. So... yeah, it's a good point.
(DIR) Post #APZSP9JTfPiBISZLMm by helge@mastodon.social
2022-11-11T23:14:11Z
0 likes, 0 repeats
@cocoaphony @matt @jjoelson @mattiem @kyle @krzyzanowskim I think they are perfectly proper, they are just not actors or what people expect actors to be.
(DIR) Post #APZSP9WaseCfx8hooK by cocoaphony@mastodon.social
2022-11-11T03:29:04Z
0 likes, 0 repeats
@jjoelson @mattiem @kyle @krzyzanowskim @helge fun fact: in the Swift code I was working on over the weekend, I built an Actor (serial message processor) inside of an `actor`. I’m not sure the `actor` has really brought anything to the party :)The thing about `actor` is that it’s all about managing shared mutable state. And we’ve spent the last several years excising shared mutable state from our designs. So it’s a little weird to see it making a comeback. But I think it’s going to be ok.
(DIR) Post #APZSPA3Yu4ZhbO89CK by cocoaphony@mastodon.social
2022-11-11T23:18:16Z
0 likes, 0 repeats
@helge @matt @jjoelson @mattiem @kyle @krzyzanowskim But I think the point is kind of on the nose. "By what example do we expect that?"I agree that iOS devs expect actors to be serial queues. But why, given that in various Actor systems, there's often a lot of work done to make them more like Swift?(And I agree that when I encountered Swift actors, my expectation was "serial queue.")
(DIR) Post #APZSPAhcV8cLbcs8dU by helge@mastodon.social
2022-11-11T23:24:39Z
0 likes, 0 repeats
@cocoaphony @matt @jjoelson @mattiem @kyle @krzyzanowskim I don’t expect actors to be serial queues at all (ie the fifo aspects), an actor to me is sth that reliably isolates shared state. A Swift actor doesn’t do that and this is what it makes hard to reason about.
(DIR) Post #APZSPBGMPyPHLN7smm by cocoaphony@mastodon.social
2022-11-12T01:34:12Z
0 likes, 0 repeats
@helge @matt @jjoelson @mattiem @kyle @krzyzanowskim Can you explain this more? In my experience, Swift actors seem to isolate shared state very well. What flaws are you thinking of?
(DIR) Post #APZSPBp6KoCD57Ncw4 by Migueldeicaza@mastodon.social
2022-11-12T01:55:22Z
0 likes, 0 repeats
@cocoaphony @helge @matt @jjoelson @mattiem @kyle @krzyzanowskim i think the issue Helge is referring to is that “a; b; c” if you insert an await at b you can no longer assume there was no re-entrancy. Your state could have changed, which is unexpected.
(DIR) Post #APZSPCQg56FmxexdVQ by uliwitness@chaos.social
2022-11-12T09:13:25Z
0 likes, 0 repeats
@Migueldeicaza @cocoaphony @helge @matt @jjoelson @mattiem @kyle @krzyzanowskim Isn't that exactly _why_ we have 'await' as a marker in Swift? So that the programmer is reminded this point could yield and doesn't keep shared state across that boundary?
(DIR) Post #APZSPD69atQl2IMl9c by helge@mastodon.social
2022-11-12T12:06:11Z
0 likes, 0 repeats
@uliwitness @Migueldeicaza @cocoaphony @matt @jjoelson @mattiem @kyle @krzyzanowskim Jein. This is separate to the actor concept and internal to it. I.e. the API consumer of an "actor" can't know whether the implementation yields internally.I don't think there is something wrong w/ the concept per se. The reason _why_ it is the way it is, is sound. It just isn't what an "actor" is to me, which I (and apparently others) find confusing. But hey 🤷♀️
(DIR) Post #APZSPEmjK558GdIH9k by cocoaphony@mastodon.social
2022-11-12T13:19:30Z
0 likes, 0 repeats
@helge @uliwitness @Migueldeicaza @matt @jjoelson @mattiem @kyle @krzyzanowskim the caller can definitely tell if the implementation may yield internally. That’s the whole meaning of the “async” in the function signature. A non-async actor method is atomic.It’s just that “async” tends to spread and there is no way to synchronously block on an async call so you can never transition back to that atomic world. (Which is why async spreads.)
(DIR) Post #APZSPFHDUjT5nBYcfx by jjoelson@mastodon.social
2022-11-13T13:49:06Z
0 likes, 0 repeats
@krzyzanowskim @Migueldeicaza @matt @uliwitness @mattiem @helge @kyle @cocoaphony It's possible async/await makes asynchrony *too* ergonomic such that people mindlessly add it where they shouldn't.E.g. it's easy to write this:func foo() async { let bar = await loadBar() // Complex logic}when we should probably write this:func foo(bar: Bar) { // Complex logic}
(DIR) Post #APZSPG6GQwIkLVROF6 by jjoelson@mastodon.social
2022-11-13T13:49:07Z
0 likes, 0 repeats
@krzyzanowskim @Migueldeicaza @matt @uliwitness @mattiem @helge @kyle @cocoaphony I always try to keep async orchestration and complex domain logic separate. This is something we all did more naturally when asynchrony meant callbacks and pyramids of doom!
(DIR) Post #APZSPGhqBEMKE31OoS by jjoelson@mastodon.social
2022-11-13T13:56:07Z
1 likes, 0 repeats
@Migueldeicaza @kyle @mattiem @cocoaphony @krzyzanowskim @helge @matt @uliwitness Said another way: complex logic within nested closures is an obvious code smell. `await` is much more subtle.