Add support for making traits Send/Sync (opt-in), in backends where this is safe

[emarteca]

Some traits we want to pass across the language boundary are also bound by Send and Sync.

We should: add a config that does this automatically for any Diplomat trait marked trait Foo: Send + Sync, as long as this is safe for the backend. We will also add a tag for backends, traits_are_send_sync, to indicate if this is safe. Then, in the HIR, if we parse impl Send and/or Sync, if the backend does not safely support send and sync for traits then this will error.

[Manishearth]

thought: probably should be two configs, traits_are_send and traits_are_sync

[Manishearth]

@maurer it would be useful to know if Kotlin objects can be Send/Sync in this world. I'm assuming so but it's possible they aren't.

[Manishearth]

If it isn't we can have an unsafe opt-in in the config

[maurer]

@maurer it would be useful to know if Kotlin objects can be Send/Sync in this world. I'm assuming so but it's possible they aren't.

As it stands, they are Send/Sync in terms of invocation-safety, because the trampolines produced by JNA directly manage the thread association. See CallbackThreadInitializer for docs on how to adjust this behavior, but the default is that when a callback is triggered, it attaches the current thread to the JVM as a daemon (this setting means that the thread remains indefinitely attached, even after the callback returns, but will not block the exit of the JVM).

I said in terms of invocation-safety above to point out that Java can still race with itself, e.g. they could provide an object which has race conditions in its implementation. Since Java/Kotlin don't have a way to mark code as sync compatible in the language, there's no way for us to test for that. The actual "call into Java" portion of the API is sync-safe, but the method itself may or may not be, depending on what the Java implementor did. I'd argue that since this is an implementation of a diplomat trait, we can resolve this portion by just saying "If the diplomat trait is marked as : Sync, it is up to the foreign implementor to make sure that's actually true with appropriate language mechanisms" to mandate that they synchronized or lock in all the right places.

If we switch to a JNI/manual trampoline approach in the future, we'd need to be sure the structure pointed at by the cookie stored the calling JavaVM (this is a handle, not the actual VM, it's cheap) and used attach_current_thread to acquire the JNIEnv it needs to make the call.