Jason Earl <jason.earl@simplot.com> writes:
> The fact of the matter is that the Win32 specific bits are the parts
> that are likely to break in the new port.
Actually, what scares me about this is the probability that the Win32
port will break other platforms. The changes look to be invasive enough
to create a nontrivial risk of that.
For comparison, look at the CVS history of the recent efforts to support
IPv6 connections. Those patches have broken both IPv4 and Unix-socket
connections at different times, and are still a source of ongoing build
problems on some platforms, plus who-knows-what problems yet to be found
on platforms that aren't used by the bleeding-edge-CVS folk. I predict
that the tweaks needed to support Windows' lack of a fork() primitive
will be far worse.
BTW, I would not approve of a response along the lines of "can't you
#ifdef to the point that there are no code changes in the Unix builds?"
No you can't, unless you want to end up with an unmaintainable mess
of #ifdef spaghetti. The thing that makes this hard is the tradeoff
between making the code readable and maintainable (which requires
sharing as much code as possible across platforms) vs isolating
platform-specific considerations. Programming at this level is not
a science but an art form, and it's very hard to get it right the first
time --- especially when none of us have access to all the platforms
that the code must ultimately work on.
regards, tom lane
