James Mansion wrote:
> Andrew Chernow wrote:
>> The only problem is how to detect the first connection. In a threaded
>> environment you'd have to perform locking in connectdb, which is
>> probably not going to fly.
> Well, if you do an atomic test for a flag being zero, and if so then
> enter a critsec, do
This is not a problem, we do this in other places in libpq already.
> My understanding is that if you do WSAStartup and WSACleanup scoped to
> each connection
> then:
> - the internal counting means that only the 0 -> 1 and 1 -> 0
> transitions are expensive
> - libpq will only incur the cost if the application didn't do it already
Yes.
> So it seems that the cost is incurred by an application that:
> - makes no other use of winsock (or also does startup/cleanup often)
> - does not retain a connection (or pool) but creates and closes
> a single connection often
Correct.
> How many applications are there that match this pattern? Isn't it
> enough just to tell
> the user to do WSAStartup and WSACleanup in main() if they find they
> have a performance problem? Surely most Windows programs effectively do
> that
> anyway, often as a side effect of using a framework.
Yeah, I think an important point here is: If you are willing to call a
special PQinitWinsock() or whatever, then you can just call WSAStartup()
yourself, and the problem goes away...
I guess adding a connection parameter might help a little bit in that
you don't need an extra API call, but I'm unsure if it's worth it given
that the workaround is so simple.
In which case, we should perhaps just document the workaround using
WSAStartup() yourself, and not bother with either API or connection
parameter...
//Magnus