Closed ra0x3 closed 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.
If you have any further questions, feel free to reopen :)
@nagisa
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?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.
async fn foo()
in my librarymy_lib
my_lib
via libloadingfoo
-- is there any way to make that call tofoo
async
?