nagisa / rust_libloading

Bindings around the platform's dynamic library loading primitives with greatly improved memory safety.
https://docs.rs/libloading
ISC License
1.22k stars 100 forks source link

Does libloading allow async code? #114

Closed ra0x3 closed 1 year ago

ra0x3 commented 1 year ago
nagisa commented 1 year ago

So, first, async fn foo() -> R { ... } is just a sugar for fn foo() -> Future<R> { async { ... } }. In that sense, async functions are no different from regular functions, its just that their return type is a lil' different. And yeah, you can kinda load them with libloading, no problem.

The problem comes up when you got to ensure ABI stability. fn bar() is actually by itself equivalent to extern "Rust" fn bar(). The "Rust" ABI is not specified, and pretty much the only way to guarantee compatibility is by compiling the code with exactly the same build of the rust toolchain. Not a huge deal when statically linking; much harder to enforce when dynamically loading libraries at runtime.

nagisa commented 1 year ago

If you have any further questions, feel free to reopen :)

ra0x3 commented 1 year ago

@nagisa

nagisa commented 1 year ago

But as a follow up, so do you mean that as long as my library my_lib is a staticlib and that it's compiled with exactly the same build of the rust toolchain as the code calling fn foo() via libloading, that async code should work fine?

--crate-type=staticlib is a different thing altogether. It does not produce dynamic libraries, and the libraries it does produce cannot be loaded with libloading. You need a cdylib usually. And, yes, must be exactly the same build of the rust toolchain.