Figure out and document how registration works when plugins are loaded dynamically by dlopen

[dtolnay]

No description provided.

[dtolnay]

We may need to set up a dtor to unregister plugins on dlclose.

[mmastrac]

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.

[dtolnay]

Thanks for the warning! I filed mmastrac/rust-ctor#3 to follow up.

[mmastrac]

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.

[mathstuf]

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.

[Hpmason]

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)

[Enet4]

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.

[Hpmason]

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!