Post AhuD1WTccwPVPOulpA by krzyzanowskim@mastodon.social
(DIR) More posts by krzyzanowskim@mastodon.social
(DIR) Post #AhuD1JKzTimWermC48 by Migueldeicaza@mastodon.social
2024-05-03T13:06:31Z
0 likes, 0 repeats
Good post by @heckj on what he learned and the tradeoffs he did when designing an API for strict swift concurrency support.The best part are the regrets he has, good guidance for those of us starting on our strict journey:https://rhonabwy.com/2024/04/29/designing-a-swift-library-with-data-race-safety/
(DIR) Post #AhuD1Ku7eaThW7DlSq by krzyzanowskim@mastodon.social
2024-05-03T13:28:10Z
0 likes, 0 repeats
@Migueldeicaza @heckj these stories gives me chills. Instill hope to never have to solve that puzzle by my own
(DIR) Post #AhuD1MTxmok2PYzty4 by Migueldeicaza@mastodon.social
2024-05-03T13:44:35Z
0 likes, 0 repeats
@krzyzanowskim @heckj threading was always fraught with mistakes, we were just living blissfully unaware and blaming random instability into “I guess we will never know”
(DIR) Post #AhuD1ODjK8wdnnPxwW by krzyzanowskim@mastodon.social
2024-05-03T13:56:47Z
0 likes, 0 repeats
@Migueldeicaza @heckj I disagree. We were building synchronous first. The shift is to force us to build asynchronous first. Example: CryptoSwift uses no asynchronous code, nor specify sendability, and won't build with Swift 6. This requirement is BS
(DIR) Post #AhuD1Q26aKpnQJzi6K by Migueldeicaza@mastodon.social
2024-05-03T14:12:56Z
0 likes, 0 repeats
@krzyzanowskim @heckj on a serious note, I don’t understand the issue with this one. Would love to know why the let assignment is not enough .
(DIR) Post #AhuD1RInrjmlMOoYlc by bigzaphod@mastodon.social
2024-05-03T14:38:26Z
0 likes, 0 repeats
@Migueldeicaza @krzyzanowskim @heckj assuming this is a global variable, Swift `let` values are lazy initialized when they're global. So any thread could potentially be the first one to read it and thus initialize it the same moment another thread tries to read it and thus initialize it.
(DIR) Post #AhuD1TRjtU7c0h0iyO by krzyzanowskim@mastodon.social
2024-05-03T14:40:12Z
0 likes, 0 repeats
@bigzaphod @Migueldeicaza @heckj it could, but it isn't. there not a piece of asynchronously in the module, and that is not even public let
(DIR) Post #AhuD1Uu8TOQkX3IusC by shadowfacts@social.shadowfacts.net
2024-05-03T15:11:44.863628Z
0 likes, 0 repeats
@krzyzanowskim @bigzaphod @Migueldeicaza @heckj but your synchronous code that accesses/initializes the value could be called on any thread—unless you have some synchronization mechanism
(DIR) Post #AhuD1WTccwPVPOulpA by krzyzanowskim@mastodon.social
2024-05-03T15:23:51Z
0 likes, 0 repeats
@shadowfacts @bigzaphod @Migueldeicaza @heckj what do you even mean accessed on any thread. by whom? I don’t call it from different threads and it’s internal to the module.
(DIR) Post #AhuD1XwNBX0DwrNFHE by shadowfacts@social.shadowfacts.net
2024-05-03T15:28:56.385169Z
0 likes, 0 repeats
@krzyzanowskim @bigzaphod @Migueldeicaza @heckj you don't, but presumably there's some synchronous entry point into your code that could be invoked on any thread, so transitively the let initializer could be invoked on any thread:Thread { CryptoSwift.doWhatever()}.start()Thread { CryptoSwift.doWhatever()}.start()
(DIR) Post #AhuD1ZEqMLN5yR1Vho by krzyzanowskim@mastodon.social
2024-05-03T15:28:13Z
0 likes, 0 repeats
@shadowfacts @bigzaphod @Migueldeicaza @heckj one thing that certainly could make it worse is to sync it on MainActor. or even a single global actor. just leave it alone. it’s a constant array after all. it need an explanation why the compiler thinks otherwise. something more than saying it should go on main actor (which is wrong for peformance)
(DIR) Post #AhuD1ZcwuiebBCIlHM by krzyzanowskim@mastodon.social
2024-05-03T15:32:27Z
0 likes, 0 repeats
@shadowfacts @bigzaphod @Migueldeicaza @heckj preassumption is based on a thin air tho, that’s my point
(DIR) Post #AhuD1abDIerMC6UtDE by shadowfacts@social.shadowfacts.net
2024-05-03T15:43:23.363874Z
0 likes, 0 repeats
@krzyzanowskim @bigzaphod @Migueldeicaza @heckj you said your module is entirely synchronous, no? my point is that nothing binds your clients to that
(DIR) Post #AhucS7kPAxa3NvXuRk by krzyzanowskim@mastodon.social
2024-05-03T15:46:47Z
0 likes, 0 repeats
@shadowfacts @bigzaphod @Migueldeicaza @heckj but hese are internal let, used in synchronous context
(DIR) Post #AhucS9NR7KOcRGoavI by shadowfacts@social.shadowfacts.net
2024-05-03T15:51:03.707959Z
0 likes, 0 repeats
@krzyzanowskim @bigzaphod @Migueldeicaza @heckj but there exists some codepath from which a public caller could trigger its initialization? otherwise why does the property existthe compiler doesn't actually do that level of flow analysis (so far as I know), but it makes the assumption that that scenario exists because it can't prove otherwise
(DIR) Post #AhucSBB6Q9ic1b3lya by krzyzanowskim@mastodon.social
2024-05-03T15:56:13Z
0 likes, 0 repeats
@shadowfacts @bigzaphod @Migueldeicaza @heckj the property is for internal use. also not mutable. in theory I think I can imagine there is a codepath where it’s accessed from public api. or now. Inwant to know what compiler knows
(DIR) Post #AhucSBJxtCo8T5Cqn2 by krzyzanowskim@mastodon.social
2024-05-03T15:48:53Z
0 likes, 0 repeats
@shadowfacts @bigzaphod @Migueldeicaza @heckj if the compiler thinks different, I expect reasoning given to not throw unchecked Sendable just to silence it. is my point
(DIR) Post #AhucSD1FZl1fjcSvtg by Migueldeicaza@mastodon.social
2024-05-03T16:58:04Z
0 likes, 0 repeats
@krzyzanowskim @shadowfacts @bigzaphod @heckj his example shows the race, the external caller influences this. You might not like it, but it is catching a real problem :-)
(DIR) Post #AhucSEIeoWXnhtcLfU by krzyzanowskim@mastodon.social
2024-05-03T17:14:23Z
0 likes, 0 repeats
@Migueldeicaza @shadowfacts @bigzaphod @heckj I mean just calling something on two thread’s doesn’t make race automatically for local state. unless it’s mutated from different threads (and let isnt, is it?). it may be dalse positive. it may be actually existing codepath. but putting it on MainActor is actually bad solution.
(DIR) Post #AhucSFb7zKufjTGc64 by shadowfacts@social.shadowfacts.net
2024-05-03T17:27:18.887754Z
0 likes, 0 repeats
@krzyzanowskim @Migueldeicaza @bigzaphod @heckj it could be accessed from a different thread than it was initialized on, so it needs to be either Sendable (letting the compiler prove that's safe) or it needs to be nonisolated(unsafe) (telling the compiler that you are guaranteeing it's safe).I'm not saying blindly slapping @MainActor on things is the best solution—here it looks like CS.BigUInt should be Sendable