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.

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

[email protected] 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
> >   [email protected]               |  (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
> > [email protected] 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 [email protected]               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073