On 09/04/2014 03:49 PM, Robert Haas wrote:
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.
Hmm. Perhaps we should call drainSelfPipe() only after poll/select
returns saying that there is something in the self-pipe. That would be a
win assuming it's more common for the self-pipe to be empty.
AIUI, the only reason why we need the self-pipe thing is because on
some platforms signals don't interrupt system calls.
That's not the only reason. It also eliminates the race condition that
someone might set the latch after we've checked that it's not set, but
before calling poll/select. The same reason that ppoll and pselect exist.
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?
... and have ppoll or pselect. Yeah, seems reasonable, assuming that
ppoll/pselect is faster.
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.
I don't think there's a function to wait for a file descriptor or
semaphore at the same time.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
