Re: close() vs. closesocket() - Mailing list pgsql-hackers

>
> 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