On Tue, Sep 2, 2014 at 3:01 PM, Andres Freund <and...@2ndquadrant.com> wrote: > I'm slightly worried about the added overhead due to the latch code. In > my implementation I only use latches after a nonblocking read, but > still. Every WaitLatchOrSocket() does a drainSelfPipe(). I wonder if > that can be made problematic.
I think that's not the word you're looking for. Or if it is, then - it's already problematic. At some point I hacked up a very crude prototype that made LWLocks use latches to sleep instead of semaphores. It was slow. 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. Could we have a separate latch implementation for platforms where we know that system calls will get interrupted by signals? Alternatively, should we consider reimplementing latches using semaphores? I assume having the signal handler up the semaphore would allow the attempt to down the semaphore to succeed on return from the handler, so it would accomplish the same thing as the self-pipe trick. Basically, it doesn't feel like a good thing that we've got two sets of primitives for making a backend wait that (1) don't really know about each other and (2) use different operating system primitives. Presumably one of the two systems is better; let's figure out which one it is, use that one all the time, and get rid of the other one. -- 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
