bendk

This part sticks out to me. The rust code is invoking the future callback, the Java code sees the callback and completes the continuation handle, but for some reason `finished...

I didn't realize this issue has been sitting in the queue for so long. Does https://github.com/mozilla/uniffi-rs/pull/2211 handle your needs or is there still work to be done here?

I should have pointed you to https://github.com/mozilla/uniffi-rs/pull/2275. As far as I know, there are no more log calls in the current code. I don't think we even have a dependency...

> After some tinkering, in contrasts to my original attempt to cancel future via KeyboardInterrupt in python, the more reliable way to cancel future seems to be using signal handler...

> One observation I found is that uniffi relied on the host language to run the event_loop where bringing another async-runtime is optional. In that mentality I think one would...

> That's a very elaborate proposal, but it's difficult to comment without more specifics. > > Ultimately though, it sounds like calling back into Kotlin from Rust created threads are...

I have to admit, I don't understand the JVM issues here. However, I think we could have a general solution that looked something like this: - Add `uniffi::attach_current_thread` to the...

> Ideally this would just do a single call all in Rust by directly doing FFI calls into JNI to attach the current thread. As I mentioned, you can get...

This seems reasonable to me. I think it could be a top-level field in `uniffi.toml`.

Adding the `external-types` label -- I'm trying to collect these kinds of error for later fixing. Does this only happen with external types? It seems like your first example only...