On Sat, Jan 10, 2015 at 11:35 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> Interesting. I dimly remembered you mentioning this, that's how I
> rediscovered this message.
>
> Do you remember any details?
No, not really.
> My guess that's not so much the overhead of the latch itself, but the
> lack of the directed wakeup stuff the OS provides for semaphores.
That's possible.
> If we could replace all usages of semaphores that set immediate
> interrupts to ok, we could quite easily make the deadlock detector
> et. al. run outside of signal handlers. That would imo make it more
> robust, and easier to understand - right now the correctness of locking
> done in the deadlock detector isn't obvious. With the infrastructure in
> place it'd also allow your new parallelism code to run outside of signal
> handlers.
Yes, I would be very happy to see ImmediateInterruptOK die in a fire.
> Unfortunately currently sempahores can't be unlocked in a signal handler
> (as sysv semaphores aren't signal safe)... It'd also be not so nice to
> set both a latch and semaphores in every signal handler.
Agreed.
>> AIUI, the only reason why we need the self-pipe thing is because on
>> some platforms signals don't interrupt system calls. But my
>> impression was that those platforms were somewhat obscure.
>
> To the contrary, I think it's only very obscure platforms where signals
> still interrupt syscalls - we set SA_RESTART for pretty much
> everything. There's a couple of system calls that ignore SA_RESTART. For
> some that's defined in posix, for others it's operating system
> specific. E.g. on linux semop(), poll(), select() are defined to always
> return EINTR when interrupted.
The recent problems with test_shm_mq test failing on anole were caused
by the fact that a signal doesn't abort select() on that platform, but
does reset the timer. So a steady stream of signals results in never
reaching the timeout.
> Anyway, the discussion since cleared up that we need the self byte to
> handle a race, anyway.
Eh?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company