Re: Escaping from blocked send() reprised.

On Tue, Sep 2, 2014 at 3:01 PM, Andres Freund <andres(at)2ndquadrant(dot)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