Conversation

This Tweet was deleted by the Tweet author. Learn more

This also applies to Go but I didn't realize Swift also cut corners in this area. Java has data races but preserves memory safety in their presence. This sometimes means paying some additional performance costs to make sure it only goes quite wrong instead of horribly wrong.

Replying to

and

Not so much "cutting corners" as making tradeoffs. Swift wanted to have a zero-overhead FFI, and it's hard to see how to provide Java level guarantees without a full GC environment and expensive FFI

Replying to

and

As long as the library is thread safe, the FFI can still be zero overhead. The wrapper would only need to enforce thread safety if the library didn't already provide safe APIs. It would also be possible to have a concept of types that cannot be shared or sent between threads.

2:06 AM · Aug 14, 2019Twitter Web App

Replying to

and

That's the eventual goal—make races impossible—but today, "the library" in this case is all of Apple's existing SDKs, which are decidedly not thread safe

Replying to

and

FFI also keeps Swift tied to reference counting, and memory safe multithreaded reference counting would require pretty expensive synchronization on every retain/release. Since we're interoperating with ObjC code that doesn't do that, the extra guarantee would still be very weak

Replying to

and

Rust handles this without a performance cost. The vast majority of types like vectors, hash tables, etc. can be sent between threads (Send trait) and don't need to provide thread safety. Rc<T> is the main exception, with Arc<T> used when atomic reference counting is truly wanted.

Replying to

and

It does support shared state between threads for anything satisfying Sync, with the main non-Sync exceptions being Cell<T> and RefCell<T>. Mutex<T> is pretty much just RefCell<T> with the synchronization needed to satisfy Sync. I don't see a blocker for other languages to do it.

Show replies