Skip site navigation (1) Skip section navigation (2)

Re: Signals inheritance work - major problems

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL Win32 port list" <pgsql-hackers-win32(at)postgresql(dot)org>,"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: Signals inheritance work - major problems
Date: 2004-11-03 16:30:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
> Hi!
> 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.

Eh. Of course, another option is to moev the read_backend_variables() up
much higher in the file. Not sure if that will cause other problems, not
sitting around the code right now but the thought came up. It'd have to
be before we do our calls to set up signal handlers. But that may not be
too bad?


pgsql-hackers-win32 by date

Next:From: Tom LaneDate: 2004-11-03 20:29:34
Subject: Re: Signals inheritance work - major problems
Previous:From: Merlin MoncureDate: 2004-11-02 21:34:17
Subject: possible problem with version string in win32 port

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group