Re: Win32 signals & sockets

>> I realise it's late in the beta. But all the actually
>*complicated* code
>> in this patch is in the first patch - the splitting up of the
>> CreateProcess/ResumeThread steps and the WSADuplicateSocket code. The
>> part that moves the param file -> shared memory is a very small and
>> simple part of the patch.
>
>Maybe so, but it also puts the final nail in the coffin of the illusion
>that testing EXEC_BACKEND behavior on Unix will give any confidence
>about not having broken the code on Windows.

Not sure how it will be that much worse than what we have now. It will
certainly not check if the actual exec backend code is broken, but if
it's missing to pass a long a variable or so (which I beleive would be
the most common things in the future) it should catch it just as well as
today.

> Also I think your thumb is
>on the scales a bit because the initial patch is doing more than it had
>to in this area (you didn't need to invent struct BackendParameters,
>did you?)

No, I didn't need to do that, but I figured it was the easiest way to be
able to check the error values. Previously, the return code from
fwrite() was never checked, which cannot possibly be said to be good.

But sure, it could be changed to check the result code of every fwrite()
and fread() instead. And sure, I may have been influenced by my plans
(or the plans in general, since it's been on the TODO for ages) to
eventually move it to shared memory when I chose that path - but I still
think it's the easiest option regardless.

>It's the increase in variance between the Unix and Windows code paths
>that's really bothering me. We went into this project on the promise
>that there weren't going to be thousands of lines of #ifdef
>WIN32 stuff,
>and I'm not happy in the least with the way postmaster.c looks now, let
>alone after applying this patch.

Right. This is what I was planning to address in the "cleanup step", but
that's a lot larger changes than these... The plan to get more #ifdefs
out of there and into a port-specific file instead. It would still be
different code, but it would be in more clearly defined parts. Similar
to the rest of the win32 specific code that goes in backend/port.

//Magnus