Re: close() vs. closesocket()

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: pgsql(at)mohawksoft(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: close() vs. closesocket()
Date: 2003-04-25 16:09:10
Message-ID: 200304251609.h3PG9AL23186@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

pgsql(at)mohawksoft(dot)com wrote:
> >
> > 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.

Our code is confusing enough --- we don't need _additional_
abstraction.

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

I see WSAStartup called in a new routine to be added, win32_startup().
so there is some abstraction coming --- where it is needed.

> (2) The file I/O routines do not (or should not) work with socked descriptors.

Well, I was given two working Win32 ports, and I am going to follow
that, knowing they will work.

> (3) During debugging on the Windows side you will want to use
> WSAGetLastError to know why something isn't working.

Yep, have some of those too.

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

Again, we abstract where we have to.

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

All the stuff we _need_ to abstract will be in logical places.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-04-25 16:16:08 Re: close() vs. closesocket()
Previous Message Bruce Momjian 2003-04-25 16:03:05 Re: close() vs. closesocket()

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2003-04-25 16:16:08 Re: close() vs. closesocket()
Previous Message Bruce Momjian 2003-04-25 16:03:05 Re: close() vs. closesocket()