pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedclose() vs. closesocket()
15+ messages / 5 participants
[nested] [flat]
* close() vs. closesocket()
@ 2003-04-24 18:35 Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 01:20 ` Re: [HACKERS] close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 06:35 ` Re: close() vs. closesocket() Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
2003-04-25 12:29 ` Re: close() vs. closesocket() mlw <pgsql@mohawksoft.com>
0 siblings, 3 replies; 15+ messages in thread
From: Bruce Momjian @ 2003-04-24 18:35 UTC (permalink / raw)
To: pgsql-hackers
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [HACKERS] close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
@ 2003-04-25 01:20 ` Bruce Momjian <pgman@candle.pha.pa.us>
2 siblings, 0 replies; 15+ messages in thread
From: Bruce Momjian @ 2003-04-25 01:20 UTC (permalink / raw)
To: PostgreSQL-patches <pgsql-patches@postgresql.org>
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);
Attachments:
[text/plain] /bjm/diff (10.7K, ../../200304250120.h3P1K3701678@candle.pha.pa.us/2-%2Fbjm%2Fdiff)
download | inline:
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);
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
@ 2003-04-25 06:35 ` Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
2 siblings, 0 replies; 15+ messages in thread
From: Shridhar Daithankar @ 2003-04-25 06:35 UTC (permalink / raw)
To: pgsql-hackers
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)
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
@ 2003-04-25 12:29 ` mlw <pgsql@mohawksoft.com>
2003-04-25 14:10 ` Re: close() vs. closesocket() Tom Lane <tgl@sss.pgh.pa.us>
2003-04-25 14:13 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2 siblings, 2 replies; 15+ messages in thread
From: mlw @ 2003-04-25 12:29 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; pgsql-hackers
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?
>
>
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 12:29 ` Re: close() vs. closesocket() mlw <pgsql@mohawksoft.com>
@ 2003-04-25 14:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-04-25 14:14 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
1 sibling, 1 reply; 15+ messages in thread
From: Tom Lane @ 2003-04-25 14:10 UTC (permalink / raw)
To: mlw <pgsql@mohawksoft.com>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; pgsql-hackers
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 12:29 ` Re: close() vs. closesocket() mlw <pgsql@mohawksoft.com>
2003-04-25 14:10 ` Re: close() vs. closesocket() Tom Lane <tgl@sss.pgh.pa.us>
@ 2003-04-25 14:14 ` Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 0 replies; 15+ messages in thread
From: Bruce Momjian @ 2003-04-25 14:14 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: mlw <pgsql@mohawksoft.com>; pgsql-hackers
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 12:29 ` Re: close() vs. closesocket() mlw <pgsql@mohawksoft.com>
@ 2003-04-25 14:13 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 15:33 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
1 sibling, 1 reply; 15+ messages in thread
From: Bruce Momjian @ 2003-04-25 14:13 UTC (permalink / raw)
To: mlw <pgsql@mohawksoft.com>; +Cc: pgsql-hackers
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 12:29 ` Re: close() vs. closesocket() mlw <pgsql@mohawksoft.com>
2003-04-25 14:13 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
@ 2003-04-25 15:33 ` pgsql@mohawksoft.com
2003-04-25 15:34 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 15+ messages in thread
From: pgsql@mohawksoft.com @ 2003-04-25 15:33 UTC (permalink / raw)
To: pgman@candle.pha.pa.us; +Cc: pgsql@mohawksoft.com; pgsql-hackers
*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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 12:29 ` Re: close() vs. closesocket() mlw <pgsql@mohawksoft.com>
2003-04-25 14:13 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 15:33 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
@ 2003-04-25 15:34 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:17 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
0 siblings, 1 reply; 15+ messages in thread
From: Bruce Momjian @ 2003-04-25 15:34 UTC (permalink / raw)
To: pgsql@mohawksoft.com; +Cc: pgsql-hackers
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 12:29 ` Re: close() vs. closesocket() mlw <pgsql@mohawksoft.com>
2003-04-25 14:13 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 15:33 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
2003-04-25 15:34 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
@ 2003-04-25 16:17 ` pgsql@mohawksoft.com
2003-04-25 16:03 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:09 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 2 replies; 15+ messages in thread
From: pgsql@mohawksoft.com @ 2003-04-25 16:17 UTC (permalink / raw)
To: pgman@candle.pha.pa.us; +Cc: pgsql@mohawksoft.com; pgsql-hackers
>
> 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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 12:29 ` Re: close() vs. closesocket() mlw <pgsql@mohawksoft.com>
2003-04-25 14:13 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 15:33 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
2003-04-25 15:34 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:17 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
@ 2003-04-25 16:03 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:26 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
1 sibling, 1 reply; 15+ messages in thread
From: Bruce Momjian @ 2003-04-25 16:03 UTC (permalink / raw)
To: pgsql@mohawksoft.com; +Cc: pgsql-hackers
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 12:29 ` Re: close() vs. closesocket() mlw <pgsql@mohawksoft.com>
2003-04-25 14:13 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 15:33 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
2003-04-25 15:34 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:17 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
2003-04-25 16:03 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
@ 2003-04-25 16:26 ` pgsql@mohawksoft.com
2003-04-25 16:16 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 15+ messages in thread
From: pgsql@mohawksoft.com @ 2003-04-25 16:26 UTC (permalink / raw)
To: pgman@candle.pha.pa.us; +Cc: pgsql@mohawksoft.com; pgsql-hackers
> 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.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 12:29 ` Re: close() vs. closesocket() mlw <pgsql@mohawksoft.com>
2003-04-25 14:13 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 15:33 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
2003-04-25 15:34 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:17 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
2003-04-25 16:03 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:26 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
@ 2003-04-25 16:16 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:59 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
0 siblings, 1 reply; 15+ messages in thread
From: Bruce Momjian @ 2003-04-25 16:16 UTC (permalink / raw)
To: pgsql@mohawksoft.com; +Cc: pgsql-hackers
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 12:29 ` Re: close() vs. closesocket() mlw <pgsql@mohawksoft.com>
2003-04-25 14:13 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 15:33 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
2003-04-25 15:34 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:17 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
2003-04-25 16:03 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:26 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
2003-04-25 16:16 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
@ 2003-04-25 16:59 ` pgsql@mohawksoft.com
0 siblings, 0 replies; 15+ messages in thread
From: pgsql@mohawksoft.com @ 2003-04-25 16:59 UTC (permalink / raw)
To: pgman@candle.pha.pa.us; +Cc: pgsql@mohawksoft.com; pgsql-hackers
> 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.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: close() vs. closesocket()
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 12:29 ` Re: close() vs. closesocket() mlw <pgsql@mohawksoft.com>
2003-04-25 14:13 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 15:33 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
2003-04-25 15:34 ` Re: close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:17 ` Re: close() vs. closesocket() pgsql@mohawksoft.com
@ 2003-04-25 16:09 ` Bruce Momjian <pgman@candle.pha.pa.us>
1 sibling, 0 replies; 15+ messages in thread
From: Bruce Momjian @ 2003-04-25 16:09 UTC (permalink / raw)
To: pgsql@mohawksoft.com; +Cc: pgsql-hackers
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
^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2003-04-25 16:59 UTC | newest]
Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-04-24 18:35 close() vs. closesocket() Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 01:20 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 06:35 ` Shridhar Daithankar <shridhar_daithankar@persistent.co.in>
2003-04-25 12:29 ` mlw <pgsql@mohawksoft.com>
2003-04-25 14:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-04-25 14:14 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 14:13 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 15:33 ` pgsql@mohawksoft.com
2003-04-25 15:34 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:17 ` pgsql@mohawksoft.com
2003-04-25 16:03 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:26 ` pgsql@mohawksoft.com
2003-04-25 16:16 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-04-25 16:59 ` pgsql@mohawksoft.com
2003-04-25 16:09 ` Bruce Momjian <pgman@candle.pha.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox