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