-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Send and Sync for declared classes #634
Comments
Actually, it's because the type is converted to roughly: struct MyClass {
superclass: NSObject,
ivars: PhantomData<Ivars>,
} And the superclass
Yeah, this applies to user-created classes too. Note that I'm working on changing a lot of things in that module, see #563.
It's been a while since I looked into this myself, so the details are a bit out of my cache, but I think the requirements are:
Definitely won't close this before that is done ;)
Yeah, that should be doable, ideally we'd mark I'll try to make this work some time after I resolve #563, thanks for the excellent suggestion! |
Cool, thanks!
Out of curiosity, how can we determine this in the general case? The documentation does not really ever mention such low-level concern, or is it that it only does when there is concern for it? For example, an exotic class I'll have to inherit from is |
The only indicators for whether something is thread-safe is:
If either of these are not present, then you should generally assume the class to be thread-unsafe. Specifically for You can apply similar reasoning to other classes, but it's difficult!
Yeah, there isn't really anything I can do to help with this, Objective-C is just by default thread unsafe, and Apple's APIs are underdocumented in this regard, that's just the sad state of affairs (though they are focused on it themselves, e.g. with the upcoming Swift 6 release they're really going all-in on thread safety in Swift). |
Hi again!
This is a bit of a mix between a question and a feature suggestion, I guess.
Question part
When using
objc2::declare_class!
, values of the resulting type are neverSend
norSync
, even when its instance variables type verifies<Self as DeclaredClass>::Ivars: Send + Sync
, due to the use ofManuallyDrop
. However, theobjc2::mutability
module's types seem to suggest that when the ivars are indeedSend + Sync
, then the global type is so as well, but needs to be added manually. That last part feels quite scary to write, especially considering theManuallyDrop
in the wrapper type and regardingSync
, even when having astatic_assertions::assert_impl_all!(MyClassIvars: Send, Sync);
for safety.Therefore, the questions:
unsafe impl
these traits on a declared class when the right conditions between theDeclaredClass::Ivars
andClassType::Mutability
declarations are met?Suggestion part
objc2::declare_class!
' and theobcj2::mutability
types' documentations would be nice? It would be easy to do and would help reassuring users (amongst them me, that is) when they have tounsafe impl
the concerned traits.objc2::declare_class!
by somehow conditionally do so depending on whether the traits are verified, or by adding blanket implementations resemblingManuallyDrop
and implement the traits for it only when the contained ivars have them. This could help a lot in various situations with respect to safety,async
being my primary concern, especially regarding the generated binding crates.The text was updated successfully, but these errors were encountered: