Re: Can a windows DLL have more than one process attached?

On Tue, Nov 27, 2001 at 01:31:40PM -0500, Tom Lane wrote:
> In reviewing some recent patches I notice the following code added to
> src/interfaces/libpq/libpqdll.c:
>
> BOOL WINAPI
> DllMain(HINSTANCE hinstDLL, DWORD fdwReason,
> LPVOID lpReserved)
> {
> switch (fdwReason)
> {
> case DLL_PROCESS_ATTACH:
> ...
> if (netmsgModule == NULL)
> netmsgModule = LoadLibraryEx("netmsg.dll", NULL, LOAD_LIBRARY_AS_DATAFILE);
> break;
> case DLL_PROCESS_DETACH:
> if (netmsgModule != NULL)
> FreeLibrary(netmsgModule);
> ...
> break;
> }
> }
>
> where netmsgModule is
>
> static HINSTANCE netmsgModule = NULL;
>
> This sure looks to me like it will fail miserably if more than one
> process can attach to the DLL concurrently: won't the first one to
> detach release the netmsg library, breaking access to it for all the
> remaining processes?
>
> I don't know enough about Windows to know if there's really a problem
> here, but the code looks fishy to me. I'd expect to need a reference
> count. Comments anyone?

I'm not much of a WinAPI coder, either, but ISTR something from the Wine
project, and found this:

http://www.allapi.net/apilist/apifunction.php?apifunction=FreeLibrary

FreeLibrary

The FreeLibrary function decrements the reference count of the
loaded dynamic-link library (DLL) module.

So it's doing the reference counting.

'Offical' reference at:

http://msdn.microsoft.com/library/en-us/dllproc/dll_3cs9.asp?frame=false

However, there's another problem. According to the above, and:

http://msdn.microsoft.com/library/en-us/dllproc/dll_4abc.asp?frame=true

It is not safe to call FreeLibrary or LoadLibraryEx from DllMain.

Which points to:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/dll_8asu.asp

Warning On attach, the body of your DLL entry-point function
should perform only simple initialization tasks, such as
setting up thread local storage (TLS), creating objects, and
opening files. You must not call LoadLibrary in the entry-point
function, because you may create dependency loops in the DLL load
order. This can result in a DLL being used before the system
has executed its initialization code. Similarly, you must not
call the FreeLibrary function in the entry-point function on
detach, because this can result in a DLL being used after the
system has executed its termination code.

Any real windows coders know if this is a problem?

Ross