Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

On Thu, Aug 4, 2011 at 17:52, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alex Hunsaker <badalex(at)gmail(dot)com> writes:
>> On Thu, Aug 4, 2011 at 16:34, David E. Wheeler <david(at)kineticode(dot)com> wrote:
>>> On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote:
>>>> 3) local %SIG before we call their trigger function. This lets signals
>>>> still work while "in trigger scope" (like we do for %_TD)
>
>>> +1
>
>> That seems to be what most people up-thread thought as well. I dont
>> see it being too expensive. Ill see if I can whip something up today.
>
> The scenario I was imagining was:
> [ $SIG{ALRM} + statement timeout-- what happens?]
> ....
> Even if you don't think statement_timeout is a particularly critical
> piece of functionality, similar interference with the delivery of, say,
> SIGUSR1 would be catastrophic.

Yipes, I see your point.

> How do you propose to prevent this sort of problem?

Well, I think that makes it unworkable.

So back to #1 or #2.

For plperlu sounds like we are going to need to disallow setting _any_
signals (minus __DIE__ and __WARN__). I should be able to make it so
when you try it gives you a warning something along the lines of
"plperl can't set signal handlers, ignoring...".

For plperl I think we should probably do the same. It seems like
Andrew might disagree though? Anyone else want to chime in on if
plperl lets you muck with signal handlers?

Im not entirely sure how much of this is workable, I still need to go
through perl's guts and see. At the very worst I think we can mark
each signal handler that is exposed in %SIG readonly (which would mean
we would die instead of warning), but I think I can make the warning
variant workable as well.

I also have not dug deep enough to know how to handle __WARN__ and
__DIE__ (and exactly what limitations allowing those will impose). I
still have some work at $day_job before I can really dig into this.