On Mon, Aug 08, 2011 at 01:23:08AM -0600, Alex Hunsaker wrote:
> On Sun, Aug 7, 2011 at 17:06, Tim Bunce <Tim.Bunce@pobox.com> wrote:
>
> > Localizing an individual element of %SIG works fine.
> > In C that's something like this (untested):
> >
> > hv = gv_fetchpv("SIG", 0, SVt_PVHV);
> > keysv = ...SV containing "ALRM"...
> > he = hv_fetch_ent(hv, keysv, 0, 0);
> > if (he) { /* arrange to restore existing elem */
> > save_helem_flags(hv, keysv, &HeVAL(he), SAVEf_SETMAGIC);
> > }
> > else { /* arrange to delete a new elem */
> > SAVEHDELETE(hv, keysv);
> > }
>
> I played with this a bit... and found yes, it locals them but no it
> does not fix the reported problem. After playing with things a bit
> more I found even "local $SIG{'ALRM'} = .,..; alarm(1);" still results
> in postgres crashing. To wit, local does squat. AFAICT it just resets
> the signal handler back to the default with SIG_DFL. (Which in
> hindsight I don't know what else I expected it to-do...)
Ah, yes. Hindsight is great. I should have spotted that. Sorry.
> So I think for this to be robust we would have to detect what signals
> they set and then reset those back to what postgres wants. Doable, but
> is it worth it? Anyone else have any bright ideas?
I'm only considering ALRM. At least that's the only one that seems worth
offering some limited support for. The others fall under "don't do that".
After giving it some more thought it seems reasonable to simply force the
SIGALRM handler back to postgres when a plperlu function returns:
pqsignal(SIGALRM, handle_sig_alarm);
Tim.