On 2014-09-02 21:46:29 +0300, Heikki Linnakangas wrote:
> I was going to suggest using WaitLatchOrSocket instead of sleeping in 1
> second increment, but I see that WaitLatchOrSocket() doesn't currently
> support waiting for a socket to become writeable, without also waiting for
> it to become readable. I wonder how difficult it would be to lift that
> restriction.
It's imo not that difficult. I've a prototype patch for that
somewhere. I tested my poll() implementation and it worked, but didn't
yet get to select().
> I also wonder if it would be simpler to keep the socket in blocking mode
> after all, and just close() in the signal handler if PqCommBusy == true. If
> the signal arrives while sleeping in send(), the effect would be the same as
> with your patch. If the signal arrives while sending, but not sleeping, you
> would not get the chance to send the already-buffered data to the client.
> But maybe that's OK, whether or not you're blocked is not very deterministic
> anyway.
I've actually been working on a patch to make the whole interaction with
the client using sockets. The reason I started so is that we lots of far
to complex stuff in signal handlers, and using a latch would allow us to
instead interrupt send/recv. While still heavily WIP the reduction in
odd stuff (check e.g. HandleCatchupInterrupt()) made me rather happy.
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.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services