Re: close() vs. closesocket() - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: close() vs. closesocket() |
Date | |
Msg-id | 200304251534.h3PFYu817988@candle.pha.pa.us Whole thread Raw |
In response to | Re: close() vs. closesocket() (pgsql@mohawksoft.com) |
Responses |
Re: close() vs. closesocket()
(pgsql@mohawksoft.com)
|
List | 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, Pennsylvania19073
pgsql-hackers by date: