So I did a proof-of-concept implementation of the inherit-signals code,
and hit some major problems.
As it is now, we start signals as the very first thing when the backend
starts (actually, we do WSAStartup() first, but I already changed the
order of those).
We clearly cannot continue doing this if we want to use an inherited
handle, since we haven't read the backend file at this time, and the
backend file is what tells us about the signals pipe to use.
But if I move the signals initialization code to after the backend file
read, that is a *lot* later. This is also *after* the backend has set up
it's signal handlers, which will crash if things aren't initialized.
In order to work around this, things have to be made much uglier than we
thought. We'd have to put a separate parameter on the commandline, not
in the backend file. And this commandline has to be parsed in main.c,
before we do pretty much anything else at all.
Looking at things, I can't help but think: If we create the pipe as the
very first command run in the new backend, the window where we'd lose a
signal is *extremely* small. Perhaps the better change is to make any
points that need to signal the backends at this point try more than once
tos end the signal? (kill() will return an error code in this case).
As long as we get the pipe set up, we will not lose any signals, even if
we haven't set up the handler yet. Because the signal mask is only
checked when running pgwin32_dispatch_queued_signals(), and we don't do
that until after we have set up the signal handler.
Do we go down the uglier path, or do you perhaps have a third idea? It
certainly can be done, but it's ugly enough that I figure it'd better be
discussed before I go ahead and do something.
pgsql-hackers-win32 by date
|Next:||From: Merlin Moncure||Date: 2004-11-02 21:34:17|
|Subject: possible problem with version string in win32 port|
|Previous:||From: Bruce Momjian||Date: 2004-11-02 19:44:22|
|Subject: Re: [pgsql-hackers-win32] Edit query buffer|