Re: Escaping from blocked send() reprised.

On Sat, Jan 10, 2015 at 11:35 AM, Andres Freund <andres(at)2ndquadrant(dot)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