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
