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

> > It is not safe to call FreeLibrary or LoadLibraryEx from DllMain.
>
> This looks ugly, although I'm not sure if it's really a problem for
us.
> I don't see how our pointing to netmsg could create a dependency loop.
Shouldn't happen in this case, no - it's probably a generic warning
message... Still, it's not recommended behaviour...

> I'm also wondering just exactly how Microsoft expects one DLL
> to be able
> to safely reference another, if it's unsafe to call FreeLibrary during
> detach --- what else are you supposed to do, leak the reference count?
If you reference the library during compilation (e.g. you link with the
.LIB file that corresponds to the .DLL), the OS will handle that as part
of the CreateProcess() call.

As for the FreeLibrary problem, you also have to deal with:
There are cases in which the entry-point function is called for a
terminating thread even if the DLL never attached to the thread - for
example, the entry-point function was never called with the
DLL_THREAD_ATTACH value in the context of the thread in either of these
two situations:
* The thread was the initial thread in the process, so the system called
the entry-point function with the DLL_PROCESS_ATTACH value.
* The thread was already running when a call to the LoadLibrary function
was made, so the system never called the entry-point function for it.

In general, depending on doing things in DllMain is not a good idea.
The fact that we do WSAStartup() in it is even deprecated in the docs
now, for the same reason: "Calling Win32 functions other than TLS,
object-creation, and file functions may result in problems that are
difficult to diagnose. For example, calling User, Shell, COM, RPC, and
Windows Sockets functions (or any functions that call these functions)
can cause access violation errors, because their DLLs call LoadLibrary
to load other system components".

The question is if it should be moved to the connection functions, or if
it shuold be left up to the application to do it. Moving it to the
connection functino would be easy, but each call to WSAStartup() should
have a corresponding WSACleanup() call...
Or if we should just leave it :-) Because it appears to work...

> If this is a problem, a possible answer is not to try to cache the
> netmsg reference at all, but just to load and unload that DLL at the
> single point where it's used. Since we only use it to translate
> socket error reports, there's probably no big performance penalty
> involved to do it that way.
That's probably the best idea.

> (1) netmsgModule and winsock_strerror_buf are declared as static
> variables in libpq/win32.h. Unless Windows has some truly creative
new
> interpretation of static variables, this means that there'll be a
> separate instance of these vars in each .c file that #includes
win32.h.
> Wasting half a K of space per .c file is the least of the
consequences.
static is static in Windows as well (it is C, after all...) If it's
declared static in the header file, there will be a separate instance in
each C file.

> I'd be happy to change the code to something that looks reasonable to
> me, but I'm in no position to test it.
I can probably do some testing - assuming the 7.2 client libs can still
talk to 7.1 servers, since I haven't any servers up on the new version
yet...

//Magnus