It has been brought to my attention by Tokuharu Yuzawa that our calling
of WSAStartup() in DllMain() (libpqdll.c) is incorrect. Basically we're
calling WSAStartup() so that the client application does not have to.
However, due to the fact that WSAStartup() can itself load libraries,
there is a risk of deadlocking here. See for example:
MSDN docs
http://msdn2.microsoft.com/en-us/library/aa910684.aspx
MIT Kerberos have had the same problem:
http://mailman.mit.edu/pipermail/krbdev/2005-March/003244.html
And even MS had the same bug in their own native database library:
http://support.microsoft.com/kb/818539
There's also a note about socket issues in DLLs on:
http://support.microsoft.com/kb/q237572/
The easy fix for this is to remove the calls. Which obviously will break
some client apps. A fairly easy fix for the WSAStartup() call is to have
a check in the connection functions against a global variable that will
then make sure to call WSAStartup() the first time it's called.
That would leave us "leaking" the WSAStartup() call, but only one per
application. This is not perfect, but I'm thinking we can maybe live
with that.
If not, perhaps we can have it call WSAStartup() everytime we connect to
a server, and then WSACleanup() when we shut down that connection with
PQfinish(). We're still going to leak if the user forgets to run
PQfinish(), but we're leaking other resources as well in that case. That
will break if any network related functions are called when there is no
connection open, but I doubt that's possible?
Of course, if we had a libpq_init() and a libpq_shutdown() function
things would be very easy, but we don't. And adding it just for this
purpose seems like trying too hard.
Yet another option would be to require that the client app deal with the
startup/shutdown code itself, but that will seriously break backwards
compatibility, so I don't think that's a good idea at all.
Other ideas?
//Magnus
