Looking at libpq, you can see Win32 requires closesocket() while Unix
uses just uses close().

I have to add this type of change to the backend for Win32, so I am
inclined to make all the socket close calls closesocket() and #define
that as close() on Unix?  It would remove quite a few Win32 defs from
libpq too.

Comments?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


Thu, 24 Apr 2003 14:35:02 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
close() vs. closesocket()
The following applied patch uses closesocket() for all socket closing
because Win32 requires it, and uses a #define to map that to close() on
Unix.

This patch removes several #ifdef WIN32 defines from libpq.  Yea!

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Looking at libpq, you can see Win32 requires closesocket() while Unix
> uses just uses close().
> 
> I have to add this type of change to the backend for Win32, so I am
> inclined to make all the socket close calls closesocket() and #define
> that as close() on Unix?  It would remove quite a few Win32 defs from
> libpq too.
> 
> Comments?
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: src/backend/libpq/hba.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/libpq/hba.c,v
retrieving revision 1.99
diff -c -c -r1.99 hba.c
*** src/backend/libpq/hba.c	17 Apr 2003 22:26:01 -0000	1.99
--- src/backend/libpq/hba.c	25 Apr 2003 01:16:51 -0000
***************
*** 1212,1218 ****
  															ident_user);
  				}
  			}
! 			close(sock_fd);
  		}
  	}
  	return ident_return;
--- 1212,1218 ----
  															ident_user);
  				}
  			}
! 			closesocket(sock_fd);
  		}
  	}
  	return ident_return;
Index: src/backend/libpq/pqcomm.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/libpq/pqcomm.c,v
retrieving revision 1.151
diff -c -c -r1.151 pqcomm.c
*** src/backend/libpq/pqcomm.c	22 Apr 2003 00:08:06 -0000	1.151
--- src/backend/libpq/pqcomm.c	25 Apr 2003 01:16:52 -0000
***************
*** 150,156 ****
  	if (MyProcPort != NULL)
  	{
  		secure_close(MyProcPort);
! 		close(MyProcPort->sock);
  		/* make sure any subsequent attempts to do I/O fail cleanly */
  		MyProcPort->sock = -1;
  	}
--- 150,156 ----
  	if (MyProcPort != NULL)
  	{
  		secure_close(MyProcPort);
! 		closesocket(MyProcPort->sock);
  		/* make sure any subsequent attempts to do I/O fail cleanly */
  		MyProcPort->sock = -1;
  	}
***************
*** 228,234 ****
  		snprintf(portNumberStr, sizeof(portNumberStr), "%d", portNumber);
  		service = portNumberStr;
  	}
! 	
  	ret = getaddrinfo2(hostName, service, &hint, &addrs);
  	if (ret || addrs == NULL)
  	{
--- 228,234 ----
  		snprintf(portNumberStr, sizeof(portNumberStr), "%d", portNumber);
  		service = portNumberStr;
  	}
! 
  	ret = getaddrinfo2(hostName, service, &hint, &addrs);
  	if (ret || addrs == NULL)
  	{
***************
*** 470,476 ****
  void
  StreamClose(int sock)
  {
! 	close(sock);
  }
  
  /*
--- 470,476 ----
  void
  StreamClose(int sock)
  {
! 	closesocket(sock);
  }
  
  /*
Index: src/backend/postmaster/pgstat.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/postmaster/pgstat.c,v
retrieving revision 1.32
diff -c -c -r1.32 pgstat.c
*** src/backend/postmaster/pgstat.c	20 Mar 2003 03:34:56 -0000	1.32
--- src/backend/postmaster/pgstat.c	25 Apr 2003 01:16:53 -0000
***************
*** 235,241 ****
  
  startup_failed:
  	if (pgStatSock >= 0)
! 		close(pgStatSock);
  	pgStatSock = -1;
  
  	/* Adjust GUC variables to suppress useless activity */
--- 235,241 ----
  
  startup_failed:
  	if (pgStatSock >= 0)
! 		closesocket(pgStatSock);
  	pgStatSock = -1;
  
  	/* Adjust GUC variables to suppress useless activity */
***************
*** 359,368 ****
  pgstat_close_sockets(void)
  {
  	if (pgStatPmPipe[0] >= 0)
! 		close(pgStatPmPipe[0]);
  	pgStatPmPipe[0] = -1;
  	if (pgStatPmPipe[1] >= 0)
! 		close(pgStatPmPipe[1]);
  	pgStatPmPipe[1] = -1;
  }
  
--- 359,368 ----
  pgstat_close_sockets(void)
  {
  	if (pgStatPmPipe[0] >= 0)
! 		closesocket(pgStatPmPipe[0]);
  	pgStatPmPipe[0] = -1;
  	if (pgStatPmPipe[1] >= 0)
! 		closesocket(pgStatPmPipe[1]);
  	pgStatPmPipe[1] = -1;
  }
  
***************
*** 1120,1126 ****
  	 * Close the writing end of the postmaster pipe, so we'll see it
  	 * closing when the postmaster terminates and can terminate as well.
  	 */
! 	close(pgStatPmPipe[1]);
  	pgStatPmPipe[1] = -1;
  
  	/*
--- 1120,1126 ----
  	 * Close the writing end of the postmaster pipe, so we'll see it
  	 * closing when the postmaster terminates and can terminate as well.
  	 */
! 	closesocket(pgStatPmPipe[1]);
  	pgStatPmPipe[1] = -1;
  
  	/*
***************
*** 1167,1179 ****
  
  		case 0:
  			/* child becomes collector process */
! 			close(pgStatPipe[1]);
! 			close(pgStatSock);
  			break;
  
  		default:
  			/* parent becomes buffer process */
! 			close(pgStatPipe[0]);
  			pgstat_recvbuffer();
  			exit(0);
  	}
--- 1167,1179 ----
  
  		case 0:
  			/* child becomes collector process */
! 			closesocket(pgStatPipe[1]);
! 			closesocket(pgStatSock);
  			break;
  
  		default:
  			/* parent becomes buffer process */
! 			closesocket(pgStatPipe[0]);
  			pgstat_recvbuffer();
  			exit(0);
  	}
Index: src/include/c.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/c.h,v
retrieving revision 1.139
diff -c -c -r1.139 c.h
*** src/include/c.h	22 Apr 2003 02:18:09 -0000	1.139
--- src/include/c.h	25 Apr 2003 01:16:55 -0000
***************
*** 721,726 ****
--- 721,733 ----
  #define unlink(from, to)	pgunlink(from, to)
  #endif
  
+ /*
+  *	Win32 requires a special close for sockets and pipes, while on Unix
+  *	close() does them all.
+  */
+ #ifndef WIN32
+ #define	closesocket close
+ #endif
    
  /* These are for things that are one way on Unix and another on NT */
  #define NULL_DEV		"/dev/null"
Index: src/interfaces/libpq/fe-connect.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.234
diff -c -c -r1.234 fe-connect.c
*** src/interfaces/libpq/fe-connect.c	22 Apr 2003 00:08:07 -0000	1.234
--- src/interfaces/libpq/fe-connect.c	25 Apr 2003 01:16:58 -0000
***************
*** 956,962 ****
  		/* ignore connect() failure if we have more addrs to try */
  		if (addr_cur->ai_next != NULL)
  		{
! 			close(conn->sock);
  			conn->sock = -1;
  			continue;
  		}
--- 956,962 ----
  		/* ignore connect() failure if we have more addrs to try */
  		if (addr_cur->ai_next != NULL)
  		{
! 			closesocket(conn->sock);
  			conn->sock = -1;
  			continue;
  		}
***************
*** 1015,1025 ****
  			if (conn->Pfdebug)
  				fprintf(conn->Pfdebug, "Postmaster reports error, attempting fallback to pre-7.0.\n");
  			pqsecure_close(conn);
- #ifdef WIN32
  			closesocket(conn->sock);
- #else
- 			close(conn->sock);
- #endif
  			conn->sock = -1;
  			conn->allow_ssl_try = FALSE;
  			return connectDBStart(conn);
--- 1015,1021 ----
***************
*** 1056,1066 ****
  	if (conn->sock >= 0)
  	{
  		pqsecure_close(conn);
- #ifdef WIN32
  		closesocket(conn->sock);
- #else
- 		close(conn->sock);
- #endif
  		conn->sock = -1;
  	}
  	conn->status = CONNECTION_BAD;
--- 1052,1058 ----
***************
*** 1935,1945 ****
  	if (conn->sock >= 0)
  	{
  		pqsecure_close(conn);
- #ifdef WIN32
  		closesocket(conn->sock);
- #else
- 		close(conn->sock);
- #endif
  	}
  	if (conn->pghost)
  		free(conn->pghost);
--- 1927,1933 ----
***************
*** 2010,2020 ****
  	if (conn->sock >= 0)
  	{
  		pqsecure_close(conn);
- #ifdef WIN32
  		closesocket(conn->sock);
- #else
- 		close(conn->sock);
- #endif
  	}
  	conn->sock = -1;
  	conn->status = CONNECTION_BAD;		/* Well, not really _bad_ - just
--- 1998,2004 ----
***************
*** 2194,2204 ****
  	}
  
  	/* Sent it, done */
- #ifdef WIN32
  	closesocket(tmpsock);
  	WSASetLastError(save_errno);
  #else
- 	close(tmpsock);
  	errno = save_errno;
  #endif
  
--- 2178,2187 ----
  	}
  
  	/* Sent it, done */
  	closesocket(tmpsock);
+ #ifdef WIN32
  	WSASetLastError(save_errno);
  #else
  	errno = save_errno;
  #endif
  
***************
*** 2210,2220 ****
  	conn->errorMessage.len = strlen(conn->errorMessage.data);
  	if (tmpsock >= 0)
  	{
- #ifdef WIN32
  		closesocket(tmpsock);
  		WSASetLastError(save_errno);
  #else
- 		close(tmpsock);
  		errno = save_errno;
  #endif
  	}
--- 2193,2202 ----
  	conn->errorMessage.len = strlen(conn->errorMessage.data);
  	if (tmpsock >= 0)
  	{
  		closesocket(tmpsock);
+ #ifdef WIN32
  		WSASetLastError(save_errno);
  #else
  		errno = save_errno;
  #endif
  	}
Index: src/interfaces/libpq/fe-exec.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-exec.c,v
retrieving revision 1.130
diff -c -c -r1.130 fe-exec.c
*** src/interfaces/libpq/fe-exec.c	22 Apr 2003 00:08:07 -0000	1.130
--- src/interfaces/libpq/fe-exec.c	25 Apr 2003 01:17:00 -0000
***************
*** 1154,1164 ****
  					  id, msgLength);
  	conn->status = CONNECTION_BAD;		/* No more connection to backend */
  	pqsecure_close(conn);
- #ifdef WIN32
  	closesocket(conn->sock);
- #else
- 	close(conn->sock);
- #endif
  	conn->sock = -1;
  }
  
--- 1154,1160 ----
Index: src/interfaces/libpq/fe-misc.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-misc.c,v
retrieving revision 1.90
diff -c -c -r1.90 fe-misc.c
*** src/interfaces/libpq/fe-misc.c	22 Apr 2003 00:08:07 -0000	1.90
--- src/interfaces/libpq/fe-misc.c	25 Apr 2003 01:17:01 -0000
***************
*** 681,691 ****
  						 "\tbefore or while processing the request.\n"));
  	conn->status = CONNECTION_BAD;		/* No more connection to backend */
  	pqsecure_close(conn);
- #ifdef WIN32
  	closesocket(conn->sock);
- #else
- 	close(conn->sock);
- #endif
  	conn->sock = -1;
  
  	return -1;
--- 681,687 ----
Index: src/interfaces/python/pgmodule.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/interfaces/python/pgmodule.c,v
retrieving revision 1.45
diff -c -c -r1.45 pgmodule.c
*** src/interfaces/python/pgmodule.c	25 Mar 2003 02:44:36 -0000	1.45
--- src/interfaces/python/pgmodule.c	25 Apr 2003 01:17:03 -0000
***************
*** 2405,2414 ****
  				n = j;		/* never used before this assignment */
  		}
  		if (n)
! 		{	
  			/* allocate buffer */
  			if (!(buffer = malloc(MAX_BUFFER_SIZE)))
! 			{		
  				PyErr_SetString(PyExc_MemoryError,
  					"can't allocate insert buffer.");
  				return NULL;
--- 2405,2414 ----
  				n = j;		/* never used before this assignment */
  		}
  		if (n)
! 		{
  			/* allocate buffer */
  			if (!(buffer = malloc(MAX_BUFFER_SIZE)))
! 			{
  				PyErr_SetString(PyExc_MemoryError,
  					"can't allocate insert buffer.");
  				return NULL;
***************
*** 2438,2444 ****
  					getsubitem = PyTuple_GetItem;
  				else
  					getsubitem = PyList_GetItem;
! 	
  				/* builds insert line */
  				bufpt=buffer;
  				bufsiz = MAX_BUFFER_SIZE - 1;
--- 2438,2444 ----
  					getsubitem = PyTuple_GetItem;
  				else
  					getsubitem = PyList_GetItem;
! 
  				/* builds insert line */
  				bufpt=buffer;
  				bufsiz = MAX_BUFFER_SIZE - 1;
***************
*** 2527,2533 ****
  					{
  						*bufpt++ = '\t'; --bufsiz;
  					}
! 			
  					if (bufsiz <= 0)
  					{
  						free(buffer);
--- 2527,2533 ----
  					{
  						*bufpt++ = '\t'; --bufsiz;
  					}
! 
  					if (bufsiz <= 0)
  					{
  						free(buffer);
***************
*** 2543,2549 ****
  				/* sends data */
  				PQputline(self->cnx, buffer);
  			}
! 	
  			/* ends query */
  			PQputline(self->cnx, "\\.\n");
  			PQendcopy(self->cnx);
--- 2543,2549 ----
  				/* sends data */
  				PQputline(self->cnx, buffer);
  			}
! 
  			/* ends query */
  			PQputline(self->cnx, "\\.\n");
  			PQendcopy(self->cnx);
Thu, 24 Apr 2003 21:20:03 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] close() vs. closesocket()
On 24 Apr 2003 at 14:35, Bruce Momjian wrote:

> Looking at libpq, you can see Win32 requires closesocket() while Unix
> uses just uses close().
> 
> I have to add this type of change to the backend for Win32, so I am
> inclined to make all the socket close calls closesocket() and #define
> that as close() on Unix?  It would remove quite a few Win32 defs from
> libpq too.

Rather than #define, I suggest we put CloseSocket as a new function and 
implement it differently.. That way we can keep track in case things start to 
differ on number and types of arguments between closesocket and close.

#define tends to add cruft and I  don't trust windows API to stability the way 
unix does.

Just an opinion..

Bye
 Shridhar

--
Why use Windows, since there is a door?(By fachat@galileo.rhein-neckar.de, 
Andre Fachat)


Fri, 25 Apr 2003 12:05:08 +0530
"Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
Re: close() vs. closesocket()
In porting to Windows, I would create a new source file called pgsocket, 
or something, and implement *all* the socket cruft there. Where ever you 
mess with a socket, i.e. send, recv,  poll,  accept, listen, 
get/setsockopt, select, etc. make it a function. Furthermore, try to 
bring some of the logical cruft that goes along with sockets and bring 
it into the module, i.e. don't call select(...) then call recv, call 
SocketSelectRead(...).

Windows' sockets aren't very good. They will be good enough to be 
functional, but eventually, someone will want to rewrite with completion 
ports.


Bruce Momjian wrote:

>Looking at libpq, you can see Win32 requires closesocket() while Unix
>uses just uses close().
>
>I have to add this type of change to the backend for Win32, so I am
>inclined to make all the socket close calls closesocket() and #define
>that as close() on Unix?  It would remove quite a few Win32 defs from
>libpq too.
>
>Comments?
>
>  
>


Fri, 25 Apr 2003 08:29:29 -0400
mlw <pgsql@mohawksoft.com>
Re: close() vs. closesocket()
mlw <pgsql@mohawksoft.com> writes:
> Windows' sockets aren't very good.

They seem to be good enough that we have not had to worry about it,
with the exception of the close/closesocket issue and the nonstandard
error reporting mechanism.  But both of those have been worked around
for a long time in the libpq sources.  Do we really need to insert a
compatibility layer just to deal with those two problems?

			regards, tom lane


Fri, 25 Apr 2003 10:10:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: close() vs. closesocket() 

We can look at such restructuring later after the port is complete but
at this point I want to get it working, and make as few changes as
possible.

---------------------------------------------------------------------------

mlw wrote:
> In porting to Windows, I would create a new source file called pgsocket, 
> or something, and implement *all* the socket cruft there. Where ever you 
> mess with a socket, i.e. send, recv,  poll,  accept, listen, 
> get/setsockopt, select, etc. make it a function. Furthermore, try to 
> bring some of the logical cruft that goes along with sockets and bring 
> it into the module, i.e. don't call select(...) then call recv, call 
> SocketSelectRead(...).
> 
> Windows' sockets aren't very good. They will be good enough to be 
> functional, but eventually, someone will want to rewrite with completion 
> ports.
> 
> 
> Bruce Momjian wrote:
> 
> >Looking at libpq, you can see Win32 requires closesocket() while Unix
> >uses just uses close().
> >
> >I have to add this type of change to the backend for Win32, so I am
> >inclined to make all the socket close calls closesocket() and #define
> >that as close() on Unix?  It would remove quite a few Win32 defs from
> >libpq too.
> >
> >Comments?
> >
> >  
> >
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


Fri, 25 Apr 2003 10:13:13 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: close() vs. closesocket()
Tom Lane wrote:
> mlw <pgsql@mohawksoft.com> writes:
> > Windows' sockets aren't very good.
> 
> They seem to be good enough that we have not had to worry about it,
> with the exception of the close/closesocket issue and the nonstandard
> error reporting mechanism.  But both of those have been worked around
> for a long time in the libpq sources.  Do we really need to insert a
> compatibility layer just to deal with those two problems?

Right.  The problem with a compatibility layer is that it adds another
level of abstraction.  That is not bad, but it might not make things
clearer either.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


Fri, 25 Apr 2003 10:14:10 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: close() vs. closesocket()
*Clearly* a sockets interface module is the *correct* way to do it. I mean,
jeez, even Steven's (RIP) used a wrapper strategy for his book on UNIX
sockets. I have been down this road so often it isn't even a subject I would
consider worth debate.

The amount of work you are talking about is trivial, what add one file to a
makefile and CVS, you still have to audit the codebase for socket I/O stuff
to make sure that standard file calls are not used on sockets. You still
have to change a number of functions to work with Windows. You are talking
about (at most) an hour extra to do it right. The bulk of work, inspecting
the code, optionally changing the socket calls, still has to be done.

As for readability, in the code pgsock_recv(...), pgsock_send(...), etc, is
a *lot* more self documenting about what's going on AND has the bonus of
allowing centralized tweeking on platforms which may or may not suppport a
strategy.

If you are going to do it, what's the point in doing half-assed?
OK, that's my $0.02.

> 
> We can look at such restructuring later after the port is complete but
> at this point I want to get it working, and make as few changes as
> possible.
> 
> ---------------------------------------------------------------------------
> 
> mlw wrote:
>> In porting to Windows, I would create a new source file called
>> pgsocket,  or something, and implement *all* the socket cruft there.
>> Where ever you  mess with a socket, i.e. send, recv,  poll,  accept,
>> listen, 
>> get/setsockopt, select, etc. make it a function. Furthermore, try to 
>> bring some of the logical cruft that goes along with sockets and bring
>>  it into the module, i.e. don't call select(...) then call recv, call 
>> SocketSelectRead(...).
>> 
>> Windows' sockets aren't very good. They will be good enough to be 
>> functional, but eventually, someone will want to rewrite with
>> completion  ports.
>> 
>> 
>> Bruce Momjian wrote:
>> 
>> >Looking at libpq, you can see Win32 requires closesocket() while Unix
>> >uses just uses close().
>> >
>> >I have to add this type of change to the backend for Win32, so I am
>> >inclined to make all the socket close calls closesocket() and #define
>> >that as close() on Unix?  It would remove quite a few Win32 defs from
>> >libpq too.
>> >
>> >Comments?
>> >
>> >  
>> >
>> 
>> 
>> ---------------------------(end of
>> broadcast)--------------------------- TIP 6: Have you searched our
>> list archives?
>> 
>> http://archives.postgresql.org
>> 
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania
>   19073
> 
> 
> ---------------------------(end of
> broadcast)--------------------------- TIP 3: if posting/reading through
> Usenet, please send an appropriate subscribe-nomail command to
> majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly


Fri, 25 Apr 2003 11:33:36 -0400 (EDT)
pgsql@mohawksoft.com
Re: close() vs. closesocket()

We have never been into abstraction for the sake of abstraction. 
Sometimes it makes things more confusing and makes it hard to see what
is actually happening.

Please provide a specific example where the abstraction would be a
benefit.

---------------------------------------------------------------------------

pgsql@mohawksoft.com wrote:
> *Clearly* a sockets interface module is the *correct* way to do it. I mean,
> jeez, even Steven's (RIP) used a wrapper strategy for his book on UNIX
> sockets. I have been down this road so often it isn't even a subject I would
> consider worth debate.
> 
> The amount of work you are talking about is trivial, what add one file to a
> makefile and CVS, you still have to audit the codebase for socket I/O stuff
> to make sure that standard file calls are not used on sockets. You still
> have to change a number of functions to work with Windows. You are talking
> about (at most) an hour extra to do it right. The bulk of work, inspecting
> the code, optionally changing the socket calls, still has to be done.
> 
> As for readability, in the code pgsock_recv(...), pgsock_send(...), etc, is
> a *lot* more self documenting about what's going on AND has the bonus of
> allowing centralized tweeking on platforms which may or may not suppport a
> strategy.
> 
> If you are going to do it, what's the point in doing half-assed?
> OK, that's my $0.02.
> 
> > 
> > We can look at such restructuring later after the port is complete but
> > at this point I want to get it working, and make as few changes as
> > possible.
> > 
> > ---------------------------------------------------------------------------
> > 
> > mlw wrote:
> >> In porting to Windows, I would create a new source file called
> >> pgsocket,  or something, and implement *all* the socket cruft there.
> >> Where ever you  mess with a socket, i.e. send, recv,  poll,  accept,
> >> listen, 
> >> get/setsockopt, select, etc. make it a function. Furthermore, try to 
> >> bring some of the logical cruft that goes along with sockets and bring
> >>  it into the module, i.e. don't call select(...) then call recv, call 
> >> SocketSelectRead(...).
> >> 
> >> Windows' sockets aren't very good. They will be good enough to be 
> >> functional, but eventually, someone will want to rewrite with
> >> completion  ports.
> >> 
> >> 
> >> Bruce Momjian wrote:
> >> 
> >> >Looking at libpq, you can see Win32 requires closesocket() while Unix
> >> >uses just uses close().
> >> >
> >> >I have to add this type of change to the backend for Win32, so I am
> >> >inclined to make all the socket close calls closesocket() and #define
> >> >that as close() on Unix?  It would remove quite a few Win32 defs from
> >> >libpq too.
> >> >
> >> >Comments?
> >> >
> >> >  
> >> >
> >> 
> >> 
> >> ---------------------------(end of
> >> broadcast)--------------------------- TIP 6: Have you searched our
> >> list archives?
> >> 
> >> http://archives.postgresql.org
> >> 
> > 
> > -- 
> >   Bruce Momjian                        |  http://candle.pha.pa.us
> >   pgman@candle.pha.pa.us               |  (610) 359-1001
> >   +  If your life is a hard drive,     |  13 Roberts Road
> >   +  Christ can be your backup.        |  Newtown Square, Pennsylvania
> >   19073
> > 
> > 
> > ---------------------------(end of
> > broadcast)--------------------------- TIP 3: if posting/reading through
> > Usenet, please send an appropriate subscribe-nomail command to
> > majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/docs/faqs/FAQ.html
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


Fri, 25 Apr 2003 11:34:56 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: close() vs. closesocket()
pgsql@mohawksoft.com wrote:
> > 
> > We have never been into abstraction for the sake of abstraction. 
> 
> Would you say that is a *good* thing or a *bad* thing?

A good thing --- too much abstraction is bad --- look at Mozilla for a
chilling example.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


Fri, 25 Apr 2003 12:03:05 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: close() vs. closesocket()
pgsql@mohawksoft.com wrote:
> > 
> > We have never been into abstraction for the sake of abstraction. 
> 
> Would you say that is a *good* thing or a *bad* thing?
> 
> > Sometimes it makes things more confusing and makes it hard to see what
> > is actually happening.
> 
> I can't think of a single instance where a reasonable (non-ansi or system
> related constructs) abstraction layer has made anything more confusing.
> Almost universally, it makes things easier to trace and debug as well as
> provides a convenient point for porting. Which, by the way, would have been
> *much* easier had it been in place to begin with.

Our code is confusing enough --- we don't need _additional_
abstraction.

> > Please provide a specific example where the abstraction would be a
> > benefit.
> 
> OK, here goes:
> 
> (1) You will need to call WSAStartup or sockets won't work.

I see WSAStartup called in a new routine to be added, win32_startup().
so there is some abstraction coming --- where it is needed.


> (2) The file I/O routines do not (or should not) work with socked descriptors.

Well, I was given two working Win32 ports, and I am going to follow
that, knowing they will work.

> (3) During debugging on the Windows side you will want to use
> WSAGetLastError to know why something isn't working.

Yep, have some of those too.

> (4) The funtion "gethostbyname" will have to be overridden because it has
> problems finding the IP address from a string IP name, i.e. "192.168.1.1"
> will not resolve because the Windows socket implementation doesn't seem to
> work. At least no on 2K that I've tested.

Again, we abstract where we have to.

> (5) Various socket cruft in casting can be done in one place.
> (6) Incidental "incompatibilities" (stuff I know I've dealt with but can't
> remember off the top of my head) can be shielded from the main code.
> 
> All this stuff should be put in one place so a developer will see it all in
> the scope of one compatibility module, rather than hunt around for all
> instances of it.

All the stuff we _need_ to abstract will be in logical places.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


Fri, 25 Apr 2003 12:09:10 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: close() vs. closesocket()
pgsql@mohawksoft.com wrote:
> > pgsql@mohawksoft.com wrote:
> >> > 
> >> > We have never been into abstraction for the sake of abstraction. 
> >> 
> >> Would you say that is a *good* thing or a *bad* thing?
> > 
> > A good thing --- too much abstraction is bad --- look at Mozilla for a
> > chilling example.
> >
> Anyone can find a *bad* example of something good. I did justify my
> statement with a "reasonable" cause.

Mozilla is an example of a case where too much abstraction is bad ---
hence supporting my statement:

> >> > We have never been into abstraction for the sake of abstraction. 

As far as examples, we are doing a few you mention already, and will
review the others once we are done.  If there are too many special
cases, we can look at abstraction, but there has to be more than what I
have seen so far.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


Fri, 25 Apr 2003 12:16:08 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: close() vs. closesocket()
> 
> We have never been into abstraction for the sake of abstraction. 

Would you say that is a *good* thing or a *bad* thing?

> Sometimes it makes things more confusing and makes it hard to see what
> is actually happening.

I can't think of a single instance where a reasonable (non-ansi or system
related constructs) abstraction layer has made anything more confusing.
Almost universally, it makes things easier to trace and debug as well as
provides a convenient point for porting. Which, by the way, would have been
*much* easier had it been in place to begin with.

> 
> Please provide a specific example where the abstraction would be a
> benefit.

OK, here goes:

(1) You will need to call WSAStartup or sockets won't work.
(2) The file I/O routines do not (or should not) work with socked descriptors.
(3) During debugging on the Windows side you will want to use
WSAGetLastError to know why something isn't working.
(4) The funtion "gethostbyname" will have to be overridden because it has
problems finding the IP address from a string IP name, i.e. "192.168.1.1"
will not resolve because the Windows socket implementation doesn't seem to
work. At least no on 2K that I've tested.
(5) Various socket cruft in casting can be done in one place.
(6) Incidental "incompatibilities" (stuff I know I've dealt with but can't
remember off the top of my head) can be shielded from the main code.

All this stuff should be put in one place so a developer will see it all in
the scope of one compatibility module, rather than hunt around for all
instances of it.




> 
> ---------------------------------------------------------------------------
> 
> pgsql@mohawksoft.com wrote:
>> *Clearly* a sockets interface module is the *correct* way to do it. I
>> mean, jeez, even Steven's (RIP) used a wrapper strategy for his book
>> on UNIX sockets. I have been down this road so often it isn't even a
>> subject I would consider worth debate.
>> 
>> The amount of work you are talking about is trivial, what add one file
>> to a makefile and CVS, you still have to audit the codebase for socket
>> I/O stuff to make sure that standard file calls are not used on
>> sockets. You still have to change a number of functions to work with
>> Windows. You are talking about (at most) an hour extra to do it right.
>> The bulk of work, inspecting the code, optionally changing the socket
>> calls, still has to be done.
>> 
>> As for readability, in the code pgsock_recv(...), pgsock_send(...),
>> etc, is a *lot* more self documenting about what's going on AND has
>> the bonus of allowing centralized tweeking on platforms which may or
>> may not suppport a strategy.
>> 
>> If you are going to do it, what's the point in doing half-assed? OK,
>> that's my $0.02.
>> 
>> > 
>> > We can look at such restructuring later after the port is complete
>> > but at this point I want to get it working, and make as few changes
>> > as possible.
>> > 
>> > ---------------------------------------------------------------------------
>> > 
>> > mlw wrote:
>> >> In porting to Windows, I would create a new source file called
>> >> pgsocket,  or something, and implement *all* the socket cruft
>> >> there. Where ever you  mess with a socket, i.e. send, recv,  poll, 
>> >> accept, listen, 
>> >> get/setsockopt, select, etc. make it a function. Furthermore, try
>> >> to  bring some of the logical cruft that goes along with sockets
>> >> and bring
>> >>  it into the module, i.e. don't call select(...) then call recv,
>> >>  call 
>> >> SocketSelectRead(...).
>> >> 
>> >> Windows' sockets aren't very good. They will be good enough to be 
>> >> functional, but eventually, someone will want to rewrite with
>> >> completion  ports.
>> >> 
>> >> 
>> >> Bruce Momjian wrote:
>> >> 
>> >> >Looking at libpq, you can see Win32 requires closesocket() while
>> >> >Unix uses just uses close().
>> >> >
>> >> >I have to add this type of change to the backend for Win32, so I
>> >> >am inclined to make all the socket close calls closesocket() and
>> >> >#define that as close() on Unix?  It would remove quite a few
>> >> >Win32 defs from libpq too.
>> >> >
>> >> >Comments?
>> >> >
>> >> >  
>> >> >
>> >> 
>> >> 
>> >> ---------------------------(end of
>> >> broadcast)--------------------------- TIP 6: Have you searched our
>> >> list archives?
>> >> 
>> >> http://archives.postgresql.org
>> >> 
>> > 
>> > -- 
>> >   Bruce Momjian                        |  http://candle.pha.pa.us
>> >   pgman@candle.pha.pa.us               |  (610) 359-1001
>> >   +  If your life is a hard drive,     |  13 Roberts Road
>> >   +  Christ can be your backup.        |  Newtown Square,
>> >   Pennsylvania 19073
>> > 
>> > 
>> > ---------------------------(end of
>> > broadcast)--------------------------- TIP 3: if posting/reading
>> > through Usenet, please send an appropriate subscribe-nomail command
>> > to majordomo@postgresql.org so that your
>> > message can get through to the mailing list cleanly
>> 
>> 
>> ---------------------------(end of
>> broadcast)--------------------------- TIP 5: Have you checked our
>> extensive FAQ?
>> 
>> http://www.postgresql.org/docs/faqs/FAQ.html
>> 
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania
>   19073


Fri, 25 Apr 2003 12:17:22 -0400 (EDT)
pgsql@mohawksoft.com
Re: close() vs. closesocket()
> pgsql@mohawksoft.com wrote:
>> > 
>> > We have never been into abstraction for the sake of abstraction. 
>> 
>> Would you say that is a *good* thing or a *bad* thing?
> 
> A good thing --- too much abstraction is bad --- look at Mozilla for a
> chilling example.
>
Anyone can find a *bad* example of something good. I did justify my
statement with a "reasonable" cause.


Fri, 25 Apr 2003 12:26:54 -0400 (EDT)
pgsql@mohawksoft.com
Re: close() vs. closesocket()
> pgsql@mohawksoft.com wrote:
>> > pgsql@mohawksoft.com wrote:
>> >> > 
>> >> > We have never been into abstraction for the sake of abstraction. 
>> >> 
>> >> Would you say that is a *good* thing or a *bad* thing?
>> > 
>> > A good thing --- too much abstraction is bad --- look at Mozilla for
>> > a chilling example.
>> >
>> Anyone can find a *bad* example of something good. I did justify my
>> statement with a "reasonable" cause.
> 
> Mozilla is an example of a case where too much abstraction is bad ---
> hence supporting my statement:
> 
>> >> > We have never been into abstraction for the sake of abstraction. 
> 
> As far as examples, we are doing a few you mention already, and will
> review the others once we are done.  If there are too many special
> cases, we can look at abstraction, but there has to be more than what I
> have seen so far.

I guess it is a design philosophy difference. My view is that all non-ansi
or system specific API which tend to differ across platforms is universally
put into an abstaction or ports layer. It has worked well for me for over
two decades. More over, every time I say to myself, "I don't need to do it
in this case." I get burned.

With sockets, particularly, there are enough difference between UNIX systems
let alone Windows to warrent an abstraction layer. PG is probably the only
non-trivial code base that I know about that does not have a sockets
abstraction layer.


Fri, 25 Apr 2003 12:59:13 -0400 (EDT)
pgsql@mohawksoft.com
Re: close() vs. closesocket()