On Sat, Jan 10, 2015 at 11:35 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
