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
{{ message }}
Repository navigation
Figure out and document how registration works when plugins are loaded dynamically by dlopen #1
Note: #[dtor] might not be enough to unregister plugins as it is currently using a libc::atexit hook. I may have to figure out a way to generate the appropriate library hooks for the ctor library for shared libraries.
I believe that I'd have to change over to using __cxa_atexit for this case. In the meantime I should also add a caveat noting that #[dtor] is probably not yet appropriate for shared libraries.
While trying to fully understand how this works, I also discovered this comment that details conditions under which OSX libraries won't be unloaded. In this case, the dtor won't run until process exit.
It turns out that dragging in core::fmt is enough to prevent a rust cdylib from unloading.
Also note that the lifetime of any symbols stored in the loaded plugin is tied to the library being loaded. So any function pointers stored anywhere while it is loaded become undefined behavior. Maybe if there were some way to attach a library lifetime to any symbol lookups, that would work to avoid unsafe behavior? Marking library unloading as unsafe with a big comment about the perils of unloading might be sufficient.
I'm a bit confused, based off the title/description of this issue it sounds like registration doesn't work with dlopen, but the README.md says that registration does happen at the time of dlopen.
I'm trying to use inventory when loading .dll's, I've tried with both the dlopen and libloading crates and plugins don't seem to be added to the registry. I don't know all the finer details of this crate and dll loading crates, so am I misunderstanding how it works? (Also, I'm on Windows just in case there's a possibility that it's an OS-specific problem)
I'm a bit confused, based off the title/description of this issue it sounds like registration doesn't work with dlopen, but the README.md says that registration does happen at the time of dlopen.
To the best of my knowledge, the registration happens during in the main application bootstrap routine (hence before main), but it does not mean that dlopen is involved. If dlopen is called as part of your application at run-time, that is not registered.
Gotcha, that makes sense. I was trying to figure out how a dynamically loaded dependency could access an existing static, which it can't lol. Thanks for clarifying!
Activity
dtolnay commentedon Dec 24, 2018
We may need to set up a
dtorto unregister plugins on dlclose.mmastrac commentedon Dec 29, 2018
Note:
#[dtor]might not be enough to unregister plugins as it is currently using alibc::atexithook. I may have to figure out a way to generate the appropriate library hooks for thectorlibrary for shared libraries.I believe that I'd have to change over to using
__cxa_atexitfor this case. In the meantime I should also add a caveat noting that#[dtor]is probably not yet appropriate for shared libraries.dtolnay commentedon Dec 29, 2018
Thanks for the warning! I filed mmastrac/linktime#3 to follow up.
mmastrac commentedon Dec 30, 2018
While trying to fully understand how this works, I also discovered this comment that details conditions under which OSX libraries won't be unloaded. In this case, the
dtorwon't run until process exit.It turns out that dragging in
core::fmtis enough to prevent a rust cdylib from unloading.mathstuf commentedon Nov 11, 2019
Also note that the lifetime of any symbols stored in the loaded plugin is tied to the library being loaded. So any function pointers stored anywhere while it is loaded become undefined behavior. Maybe if there were some way to attach a library lifetime to any symbol lookups, that would work to avoid unsafe behavior? Marking library unloading as
unsafewith a big comment about the perils of unloading might be sufficient.Hpmason commentedon Dec 27, 2022
I'm a bit confused, based off the title/description of this issue it sounds like registration doesn't work with dlopen, but the README.md says that registration does happen at the time of dlopen.
I'm trying to use
inventorywhen loading .dll's, I've tried with both thedlopenandlibloadingcrates and plugins don't seem to be added to the registry. I don't know all the finer details of this crate and dll loading crates, so am I misunderstanding how it works? (Also, I'm on Windows just in case there's a possibility that it's an OS-specific problem)Enet4 commentedon Dec 27, 2022
To the best of my knowledge, the registration happens during in the main application bootstrap routine (hence before main), but it does not mean that
dlopenis involved. Ifdlopenis called as part of your application at run-time, that is not registered.Hpmason commentedon Dec 27, 2022
Gotcha, that makes sense. I was trying to figure out how a dynamically loaded dependency could access an existing static, which it can't lol. Thanks for clarifying!