Qt-interest Archive, February 2007
Shared memory, multiple DLLs
Message 1 in thread
Hi everyone!
What means does Qt provide to use shared memory across the boundaries of
several separate Qt based DLLs (used within the same process)? In
detail, how can I set up a shared QSemaphore used by multiple DLL
instances within the same process space?
For background, we're perhaps facing the problem to have to destroy the
Q[Core]Application object on unloading the last DLL, so we need to
protect this resource until the detachment of the very last lib. We're
still investigating, but it looks like the QApp object (invoked via
QMfcApp from the QtWinMigration framework) interferes with the Windows
event loop in a way that leads to an access violation within
QCoreApplication::sendPostedEvents() on ending the process that uses the
DLLs. But only on some systems, and the root cause is still unclear
because we've got no system to reproduce and debug on, so this is merely
a workaround instead of a solution :-(
Thanks for any suggestions!
Martin
--
[ signature omitted ]
Message 2 in thread
"Martin Gebert" <Martin.Gebert@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:epse6q$43k$1@xxxxxxxxxxxxxxxxxxxxx
> Hi everyone!
>
> What means does Qt provide to use shared memory across the boundaries of
> several separate Qt based DLLs (used within the same process)? In detail,
> how can I set up a shared QSemaphore used by multiple DLL instances within
> the same process space?
Memory is shared between DLLs in the same process anyway.
How you inform all DLLs about the existance of an object that all DLLs
should know about you have to provide some means of communication. Either
all DLLs link against a DLL that exports the respective symbol (which is how
qApp works, even though you might want to use the singleton pattern), or you
inform all DLLs about the symbol from within your application (using some
sort of registration process for the DLLs, i.e. pass the address to the
entry point function).
> For background, we're perhaps facing the problem to have to destroy the
> Q[Core]Application object on unloading the last DLL, so we need to protect
> this resource until the detachment of the very last lib. We're still
> investigating, but it looks like the QApp object (invoked via QMfcApp from
> the QtWinMigration framework) interferes with the Windows event loop in a
> way that leads to an access violation within
> QCoreApplication::sendPostedEvents() on ending the process that uses the
> DLLs. But only on some systems, and the root cause is still unclear
> because we've got no system to reproduce and debug on, so this is merely a
> workaround instead of a solution :-(
The WinMigration framework does the following behind the scenes when you
call QMfcApp::pluginInstance in your DllMain function for the ATTACH-case:
If qApp is still 0, then create a QApplication object, and load the DLL
again (based in the HINSTANCE parameter you pass in). This increase the
reference count of the DLL that owns the QApplication object - the DLL will
not be unloaded even if the application that explicitly loaded the DLL as a
plugin calls FreeLibrary (unless the application calls FreeLibrary more
often that it called LoadLibray, which is of course a bug in the
application).
Other DLLs loaded later will see that qApp already exists, and just share
that instance. Those DLLs will be unloaded by the application when it calls
FreeLibrary.
The DLL owning qApp will then be unloaded by the system when the process
exits. In that case, DllMain with DETACH will be called, and you can delete
qApp in your code (based on the return value of the call to pluginInstance
earlier).
All this should also work if you link against those DLLs rather than
LoadLibrary/FreeLibrary them yourself, as the system will free the DLLs
loaded during application startup in the opposite order of which they were
loaded.
Volker
--
[ signature omitted ]
Message 3 in thread
Good morning Volker!
> Memory is shared between DLLs in the same process anyway.
>
> How you inform all DLLs about the existance of an object that all DLLs
> should know about you have to provide some means of communication. Either
> all DLLs link against a DLL that exports the respective symbol (which is how
> qApp works, even though you might want to use the singleton pattern), or you
> inform all DLLs about the symbol from within your application (using some
> sort of registration process for the DLLs, i.e. pass the address to the
> entry point function).
As we're only a supplier, our DLLs are to be simply called from the
clients app. We can't and don't want to rely on them passing pointers to
our DLLs that are for our internal use only, so we indeed need a way to
communicate and share a pointer to an existing semaphore internally.
I'll have to ask, but it may be, unfortunately, out of the question to
add another DLL just for the purpose of sharing that pointer. Yesterday
I found out about QtSharedMemory; this may be a convenient alternative.
> The DLL owning qApp will then be unloaded by the system when the process
> exits. In that case, DllMain with DETACH will be called, and you can delete
> qApp in your code (based on the return value of the call to pluginInstance
> earlier).
Thanks for this precious insight! So that's what static bool
ownApplication is for... Well, then there'd be no need for a semaphore,
if only *all* of our DLLs utilize QMfcApp.
Martin
--
[ signature omitted ]
