Thread: 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, Pennsylvania19073
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.. ByeShridhar -- 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: >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? > > 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, Pennsylvania19073
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, Pennsylvania19073
*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
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, Pennsylvania19073
> > 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
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, Pennsylvania19073
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, Pennsylvania19073
> 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. -- 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, Pennsylvania19073
> 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.