Re: libpq WSACleanup is not needed - Mailing list pgsql-hackers

From James Mansion
Subject Re: libpq WSACleanup is not needed
Date
Msg-id 497652C9.8060708@mansionfamily.plus.com
Whole thread Raw
In response to Re: libpq WSACleanup is not needed  (Andrew Chernow <ac@esilo.com>)
Responses Re: libpq WSACleanup is not needed  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
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
the init iff you're the first in, and then set the flag on the way out, 
then:- most times, you'll just have the atomic test- other times, you have a short critsec

I can't see that being a big deal considering you're about to resolve 
the server hostname
and then do a TCP/IP connect.

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

So it seems that the cost is incurred by an application that:- makes no other use of winsock (or also does
startup/cleanupoften)- does not retain a connection (or pool) but creates and closes a single connection often
 

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.

James



pgsql-hackers by date:

Previous
From: Bryce Nesbitt
Date:
Subject: Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector
Next
From: Josh Berkus
Date:
Subject: Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector