I'm working on a rather large Windows C++ desktop application that compiles its modules into DLLs using MSVC to allow to share pre-built modules (same compiler and settings are enforced, so there are no ABI issues). The layout is essentially the same as described in this question and using gRPC as a static library in multiple modules/DLLs leads to crashes or deadlocks, which I assume are precisely due to the issue described in the question mentioned above, i.e., there will be multiple instances of singletons (or other static data) of the gRPC library.
The problem should be solved, if gRPC would be available as DLL, but unfortunately building as shared libraries is not officially supported and it seems non-trivial to enable it, especially for the MSVC, since there are no __declspec(dllexport) entries in the grpc code and so no symbols are exported when I change the built to shared libraries.
Does anyone know, whether there is a reasonable and safe way to use gRPC in a software product with DLL-based modules as described above?
UPDATE 1: Since there were doubts, about whether the crashes are actually related to gRPC and the static/dynamic linking situation, I created a repository with a minimal example that reproduces issues that are observed with using gRPC in an environment as described above. I started with one example about cross-DLL use of ClientContexts.
UPDATE 2: The observed deadlocks/hangs seem to be more like a regular bug, which maybe only manifest more often in a DLL-based scenario (it is also observed in cases, where only a single DLL links the static gRPC libraries, so no duplicate static data).
Nevertheless, it seems to me that this scenario of a DLL-based application is not really supported with gRPC and that there is no really safe way to use it in such a situation. I would appreciate, if anyone could confirm this (or maybe dissent, if you actually managed to use it in a larger product). I think other users might benefit as well, if they know beforehand, what to expect.
