Re: close() vs. closesocket()

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

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

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

pgsql(at)mohawksoft(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)postgresql(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073