close() vs. closesocket()
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 19073The 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 19073Attachments:
/bjm/difftext/plainDownload
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);
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)
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:
Show quoted text
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?
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
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?
--
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 19073Tom 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*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.
Show quoted text
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?-- 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
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?-- 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?
--
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 19073pgsql@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 19073Import Notes
Reply to msg id not found: 4968.68.162.220.216.1051287442.squirrel@mail.mohawksoft.com | Resolved by subject fallback
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 19073Import Notes
Reply to msg id not found: 4968.68.162.220.216.1051287442.squirrel@mail.mohawksoft.com | Resolved by subject fallback
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 19073Import Notes
Reply to msg id not found: 1030.68.162.220.216.1051288014.squirrel@mail.mohawksoft.com | Resolved by subject fallback
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.
Show quoted text
---------------------------------------------------------------------------
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?-- 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?-- 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
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.
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.