Hi,
On 2026-04-07 17:31:18 -0400, Andrew Dunstan wrote:
> On 2026-04-07 Tu 2:19 PM, Andres Freund wrote:
> > On 2026-04-07 12:49:19 -0400, Andrew Dunstan wrote:
> > > On 2026-04-07 Tu 10:55 AM, Andres Freund wrote:
> > > > This seems completely wrong from a layering POV. The wrapper has no business
> > > > whatsoever to know that how SIGTERM is interpreted and thus no business
> > > > setting variables like ProcDieSenderPid.
> > > >
> > > > Pretty sure have some sigterm handlers that shouldn't set ProcDieSenderPid.
> > > >
> > > >
> > > > A more correct answer here would be to forward information about the sender of
> > > > a signal to the signal handlers and let them interpret the information if
> > > > available.
> > > >
> > > OK, fair points. Does the attached meet your concerns?
> > I think the extra data should be forwarded as arguments to the "real" (not
> > wrapper) handler, not as globals. You can have signal handlers interrupt each
> > others on some platforms, which means that if you're not careful, you could
> > end up reading the values from the wrong signal.
>
>
> OK, maybe this, then? It saves the siginfo before calling the handler, and
> restores it after the call, so you should always be looking at the right
> one.
I don't think that addresses my concerns at all unfortunately. I can give
writing a sketch of how I think it should like a go, but it won't be today and
probably not this week.
I suspect this patch just has missed the boat for 19, but if others think we
can fix it up in a week or two, I'm also ok. It's a feature I wanted for a
long time.
Greetings,
Andres Freund
