Re: Optimising latch signals

On Fri, Nov 13, 2020 at 12:42 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> 1. It's a bit clunky that pqinitmask() takes a new argument to say
> whether SIGURG should be blocked; that's because the knowledge of
> which latch implementation we're using is private to latch.c, and only
> the epoll version needs to block it. I wonder how to make that
> tidier.

I found, I think, a better way: now InitializeLatchSupport() is in
charge of managing the signal handler and modifying the signal mask.

> 3. Maybe it's strange to continue to use overloaded SIGUSR1 on
> non-epoll, non-kqueue systems; perhaps we should use SIGURG
> everywhere.

Fixed.

> The improvement isn't quite as good on Linux, because as far as I can
> tell you still have to have an (empty) signal handler installed and it
> runs (can we find a way to avoid that?), but you still get to skip all
> the pipe manipulation.

I received an off-list clue that we could use a signalfd, which I'd
discounted before because it still has to be drained; in fact the
overheads saved outweigh that so this seems like a better solution,
and I'm reliably informed that in a future WAIT_USE_IOURING mode it
should be possible to get rid of the read too, so it seems like a good
direction to go in.

I'll add this to the next commitfest.