Re: Escaping from blocked send() reprised.

On 09/04/2014 03:49 PM, Robert Haas wrote:
> 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.

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