Re: common signal handler protection

Hi,

On 2024-02-06 20:39:41 -0600, Nathan Bossart wrote:
> On Tue, Nov 21, 2023 at 03:20:08PM -0600, Nathan Bossart wrote:
> > * Overhead: The wrapper handler calls a function pointer and getpid(),
> >   which AFAICT is a real system call on most platforms.  That might not be
> >   a tremendous amount of overhead, but it's not zero, either.  I'm
> >   particularly worried about signal-heavy code like synchronous
> >   replication.  (Are there other areas that should be tested?)  If this is
> >   a concern, perhaps we could allow certain processes to opt out of this
> >   wrapper handler, provided we believe it is unlikely to fork or that the
> >   handler code is safe to run in grandchild processes.
> 
> I finally spent some time trying to measure this overhead.  Specifically, I
> sent many, many SIGUSR2 signals to postmaster, which just uses
> dummy_handler(), i.e., does nothing.  I was just barely able to get
> wrapper_handler() to show up in the first page of 'perf top' in this
> extreme case, which leads me to think that the overhead might not be a
> problem.

That's what I'd expect. Signal delivery is fairly heavyweight, getpid() is one
of the cheapest system calls (IIRC only beat by close() of an invalid FD on
recent-ish linux).  If it were to become an issue, we'd much better spend our
time reducing the millions of signals/sec that'd have to involve.

Greetings,

Andres Freund