>> se, it is that our pipe-based emulation of signals isn't ready to
>> collect signal messages until some time after the child
>process starts.
>>
>> Could this be fixed by having the postmaster set up the pipe
>*before* it
>> forks/execs the child? We'd probably need to pass down some
>additional
>> info to inform the child where it has to hook into the pipe
>structure,
>> but passing down more state is no problem.
>
>Not sure. Magnus?
I think it can be made to work, but it's not as easy as one would hope.
Remember, the pipe is called \\.\pipe\pqsignal_<pid>, with the current
pid as a part of it.
The way to do it, I *think*, is to change the forkexec call to do (this
is all untested):
1) CreateProcess, with the flag CREATE_SUSPENDED. This creates all the
process structures, but specifically does not start the main thread.
This gives us the process id and handle.
2) Create the pipe with the correct name
3) Call DuplicateHandle() on the pipe to make it available in the
sub-process
4) Close the original pipe handle
5) Write the new handle to the backend parameter file somewhere
6) ResumeThread() on the new process, which actually starts the backend
As you can see, this is quite a bit more complicated than the simple
CreateProcess() call we have now.
It does, however, have a different advantage as well. The same kind of
thing will be required for a fix of the infamous "socket operation on
non socket because of LSP problems" we've been seeing quite a number of
reports on. The change being that instead of DuplicateHandle() we'd do
WSADuplicateSocket() for sockets to inherit.
If this seems like a reasonable approach, I can see if I can get
something together. But it's a fairly large change..
(Or if someone can poke a hole in the idea before I start, then please
do so..)
//Magnus
