Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inline registry leads to split instances across .so borders #3003

Open
kikaxa opened this issue Feb 8, 2024 · 5 comments
Open

inline registry leads to split instances across .so borders #3003

kikaxa opened this issue Feb 8, 2024 · 5 comments

Comments

@kikaxa
Copy link

kikaxa commented Feb 8, 2024

SPDLOG_INLINE registry &registry::instance() returns local instance in each so, preventing configuration and central reuse of logger.

sample naive configuration, with most(all?) default spdlog build/use possibilities not achieving expectations:
+main exe
+shared/reused common libs(static/dynamic)
+multiple plugins .so
all using (expected to be same?) logger

@kikaxa kikaxa changed the title inline registry leads to spliced instance across .so borders inline registry leads to split instances across .so borders Feb 8, 2024
@tt4g
Copy link
Contributor

tt4g commented Feb 8, 2024

Since &registry::instance() is an internal API, the application should not call it directly.

@kikaxa
Copy link
Author

kikaxa commented Feb 9, 2024

Of course. It is the central instance that is used by everything else, including configuration, sinks and logging itself.

@tt4g
Copy link
Contributor

tt4g commented Feb 9, 2024

Is it correct that the question is about the handling of the spdlog registry when using the public API?

To give some historical background, spdlog was initially a header-only library.
It was not until version 1.4.0 that it became buildable as a shared/static library: https://github.com/gabime/spdlog/releases/tag/v1.4.0

In header-only spdlog, it was left to the developer to decide whether the memory managing the spdlog global registry should be the library's or the application's.

If you want to share the registry with spdlog built as a library, please see the Wiki.
However, the same instance of the spdlog registry built as a shared library on Linux is always shared.

There is probably no way to avoid sharing the spdlog registry between libraries and applications.
The easiest solution would be to not use the spdlog registry.
Libraries and applications should provide their own APIs to replace the spdlog registry.

@kikaxa
Copy link
Author

kikaxa commented Feb 9, 2024

Thank you.
This document is spot-on, but not easily discoverable through md, headers or cmake.
The shared library would have a tradeoffs in performance, i think?
Still, using shared in the modular program would similarly result in plugins having its own local copy of spdlog.so=registry used

Libraries and applications should provide their own APIs to replace the spdlog registry.

How do you imagine that implemented? Do not see any documented or straight-forward ways to do that..? I would expect there to be a way to say "i want to use whatever else everyone uses".

I tried overriding
# define SPDLOG_INLINE inline __attribute__ ((weak))
which achieves exactly what is expected(with some caveats as usual).

@gabime
Copy link
Owner

gabime commented Feb 9, 2024

fwiw we are thinking about ways to improve this in v2.x branch. Perhaps by adding a function to set/get the registry instance, so that dlls can be provided a registry object from the main exe, which in turn they can set as current registry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants