Ok, it's time for another one of these "Swift concurrency step-by-step" posts. It explores working with types that are not Sendable. All based around reading a model from some data store. www.massicotte.org/step-by-step... - ThreadSky

massicotte.org • 88 days ago

Ok, it's time for another one of these "Swift concurrency step-by-step" posts.

It explores working with types that are not Sendable. All based around reading a model from some data store.

https://www.massicotte.org/step-by-step-reading-from-storage

Comments

joe.inkle.co•88 days ago

Another excellent article! And you're too self-critical, every one of your posts I've read has been 💯

One question - you say "non-isolated + async means runs in the background" (and you reiterate the same later)...

joe.inkle.co•88 days ago

... My understanding was that non-isolated means "it's not constrained to a particular actor, but is guaranteed (in S6 mode?) to be safe from *any* actor"? (including Main)

Or is it really *guaranteed* to run only on a non-main actor?

joe.inkle.co•88 days ago

...and does that also guarantee a background *thread* and therefore parallelism, or is it guaranteed to be non-main-actor but potentially interleaved on the main thread?

Oh shit sorry that's not one question 😅

[apologies for spam replies, I initially replied to your bridged post from mastodon]

massicotte.org•88 days ago

First, thank you, that's super nice. Also, I have to fix this bridged account situation somehow...

Your questions are really good. The migration guide goes into a bunch of details here (https://www.swift.org/migration/documentation/swift-6-concurrency-migration-guide/dataracesafety). But quickly:

massicotte.org•88 days ago

It is a *guarantee* that a non-isolated async function will never run on any actor (https://github.com/swiftlang/swift-evolution/blob/main/proposals/0338-clarify-execution-non-actor-async.md). Effectively this makes them always "background" threads (but from a shared, fixed pool).

This is true for all versions of swift >= 5.7. Language mode does not affect language semantics.

joe.inkle.co•88 days ago

Huh, fascinating, thank you!

drewmccormack.bsky.social•88 days ago

Nice post! I was wondering about something: if I have a generic container class using locks, is it possible to add unchecked sendable conditional on the contained type being sendable? Think about something like a class based array type. I guess it should be, but not sure…

massicotte.org•88 days ago

thank you!

Hmmm that is a really interesting question. I do not know! Have you tried this and run into trouble?

drewmccormack.bsky.social•88 days ago

I have a container like this, and assumed it was ok, but your post made me realize I probably need to make it conditional on the element being sendable, even if the class itself is thread safe.

massicotte.org•88 days ago

Yeah unchecked sendable types make it easy to transport unsafe objects around to other threads. You could definitely be right.

This a common issue with custom lock implementations too.