Re: close() vs. closesocket()

From: pgsql(at)mohawksoft(dot)com
To: pgman(at)candle(dot)pha(dot)pa(dot)us
Cc: pgsql(at)mohawksoft(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: close() vs. closesocket()
Date: 2003-04-25 15:33:36
Message-ID: 2747.68.162.220.216.1051284816.squirrel@mail.mohawksoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

*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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-04-25 15:34:56 Re: close() vs. closesocket()
Previous Message Tom Lane 2003-04-25 15:13:06 Re: STABLE functions

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2003-04-25 15:34:56 Re: close() vs. closesocket()
Previous Message Bruce Momjian 2003-04-25 14:14:10 Re: close() vs. closesocket()