wuwbobo2021

@JonasVautherin I've did a simple test: your problem is probably caused by the `Send` restriction of the closure argument required by the constructor of your struct. It might work if...

I shall disagree with the idea of *merely* requiring `&mut self` in methods of `JNIEnv` in order to "solve" the problem with local frames (#392, ). - With this solution,...

Correction: The usage of transparent `JNIEnv` instead of some attachment guard (protected by the internal counter and the thread local counter, panicking or returning error on counter mismatch) must be...

It seems like `jni-rs` doesn't have a disignated place for instant messaging. I'd like to provide a temporary place: . I'm busy for now, but you can talk with other...

Excuse me, you've misunderstood my comments (maybe not clear enough). The "internal counter" I described above is stored in the guarded (non-transparent) JNIEnv, but not inside local references. Local references...

> Libraries should not be silently attaching and detaching threads. Besides being prone to failure, doing so frequently is also very slow. Could you describe more about the problem? It...

I did a performance test for myself (not based on the benchmark mentioned in ), the result shows that the performance cost of `AutoLocal` can be ignored comparing with the...

The orginal post comes from @JonasVautherin; I changed the topic (transitionally?) in . Let me explain about my thoughts briefly: To solve #558, one of these changes is required: -...

If I'm not mistaken, you want to make sure there's no more than one `AttachGuard` for each thread at any timepoint. While it looks acceptable for native libraries directly supporting...

Thanks for your comments. I guess a "safe" AttachGuard is possible if we could claim that any safe function (except TLS destructors) should not detach the current thread from JVM...