@bastiankusserow.bsky.social
Do you think that „approachable concurrency“ as outlined in the swift vision documents make that whole behavior even worse or would there be no difference after all? Did not think that through thoroughly but would be interested in your take in that regard.
March 23, 2025 at 2:32 PM
Do you think that „approachable concurrency“ as outlined in the swift vision documents make that whole behavior even worse or would there be no difference after all? Did not think that through thoroughly but would be interested in your take in that regard.
Awesome post, as always 👌 Somehow I miss the explicit `newBackgroundContext()` that core data provided here. I think that would be analogous to a new ModelContext but would make sure that it’s not bound to the main actor.
March 23, 2025 at 11:42 AM
Awesome post, as always 👌 Somehow I miss the explicit `newBackgroundContext()` that core data provided here. I think that would be analogous to a new ModelContext but would make sure that it’s not bound to the main actor.
Ah haha nice, then I’m not the only one surprised by this. Thanks for the reply!
March 15, 2025 at 2:38 PM
Ah haha nice, then I’m not the only one surprised by this. Thanks for the reply!
Would be very interested in your take on a problem I asked in the forum some days ago forums.swift.org/t/actor-prot... Seems like it could be an RBI issue but not sure if I miss something here
Actor Protocol requirement Concurrency Warning
looking at the generated SIL (via godbolt), the only difference that stands out to me is that when A conforms to Proto, there is an additional method generated, presumably for resolving calls through ...
forums.swift.org
March 15, 2025 at 2:15 PM
Would be very interested in your take on a problem I asked in the forum some days ago forums.swift.org/t/actor-prot... Seems like it could be an RBI issue but not sure if I miss something here
I don’t know. Is it safe that it’s using the main thread as isolation if the actor is created on the main thread? I’m not an expert in SwiftData but we built a similar construct for core data and it helped a lot. However, it’s never using the view context in our case.
March 8, 2025 at 8:09 PM
I don’t know. Is it safe that it’s using the main thread as isolation if the actor is created on the main thread? I’m not an expert in SwiftData but we built a similar construct for core data and it helped a lot. However, it’s never using the view context in our case.
I see, agree. I guess you have to know what you’re doing and why model actor exists in the first place, otherwise you might get unwanted behavior.
March 8, 2025 at 7:57 PM
I see, agree. I guess you have to know what you’re doing and why model actor exists in the first place, otherwise you might get unwanted behavior.
Why would you want to do all of the database stuff only on the main actor? The model actor gives a little bit of safety that mutations are not happening on the wrong thread and crash the app. If you have say a VM you would have to make sure that everything irt. SwiftData happens on the main actor
March 8, 2025 at 7:48 PM
Why would you want to do all of the database stuff only on the main actor? The model actor gives a little bit of safety that mutations are not happening on the wrong thread and crash the app. If you have say a VM you would have to make sure that everything irt. SwiftData happens on the main actor
And if I am not mistaken you can create a new model context by passing in the model container, which I believe happens under the hood
March 8, 2025 at 6:56 PM
And if I am not mistaken you can create a new model context by passing in the model container, which I believe happens under the hood
Yes, SwiftData seems to bind the model context to the current thread/executor (not sure on terminology either) the context is created on. This also is the case of you create a context from scratch. In core data this was done via `newBackgroundContext` if I’m not mistaken.
March 8, 2025 at 6:53 PM
Yes, SwiftData seems to bind the model context to the current thread/executor (not sure on terminology either) the context is created on. This also is the case of you create a context from scratch. In core data this was done via `newBackgroundContext` if I’m not mistaken.
I think it’s not inheriting the main actor but the managed object context‘s queue. You pass that in and it makes sure that everything that happens happens on the MOC the object is bound to, via a custom executor.
March 8, 2025 at 4:14 PM
I think it’s not inheriting the main actor but the managed object context‘s queue. You pass that in and it makes sure that everything that happens happens on the MOC the object is bound to, via a custom executor.