You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I encountered the following issue with Ubuntu Linux/openjdk/Kotlin/Rust development:
I'm loading a uniffied Rust libexample.so in the main thread of my console application.
So far I thought and learned, that native code loaded in the main thread is executed in the main thread.
But, after a lot of examination on the Rust, the Java/Kotlin and the os side, I found out that the NativeLoading procedures produces a second os-thread for the java process, always consecutive to the main thread and with an offset of 4.
On the rust side, this has implications: windowing (winit) does a main thread check and it will fail because processId != threadId, and we all know that the main threadId = processId.
Having the library running on another thread can also have implications for OpenGl context sharing or things like this.
However, is it possible to omit a second jna thread and let the library functions execute in exactly the context of the java main thread (and it's OS counterpart)?
Thank you for some clarification!
The text was updated successfully, but these errors were encountered:
I encountered the following issue with Ubuntu Linux/openjdk/Kotlin/Rust development:
I'm loading a uniffied Rust libexample.so in the main thread of my console application.
So far I thought and learned, that native code loaded in the main thread is executed in the main thread.
But, after a lot of examination on the Rust, the Java/Kotlin and the os side, I found out that the NativeLoading procedures produces a second os-thread for the java process, always consecutive to the main thread and with an offset of 4.
On the rust side, this has implications: windowing (winit) does a main thread check and it will fail because processId != threadId, and we all know that the main threadId = processId.
Having the library running on another thread can also have implications for OpenGl context sharing or things like this.
However, is it possible to omit a second jna thread and let the library functions execute in exactly the context of the java main thread (and it's OS counterpart)?
Thank you for some clarification!
The text was updated successfully, but these errors were encountered: