Re: Re: Overhauling our interrupt handling (was Escaping from blocked send() reprised.) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Re: Overhauling our interrupt handling (was Escaping from blocked send() reprised.)
Date
Msg-id 20150131105637.GL24213@alap3.anarazel.de
Whole thread Raw
In response to Re: Overhauling our interrupt handling (was Escaping from blocked send() reprised.)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On 2015-01-30 18:59:28 +0100, Heikki Linnakangas wrote:
> On 01/15/2015 03:03 AM, Andres Freund wrote:
> >0004: Process 'die' interrupts while reading/writing from the client socket.
> >
> >       This is the reason Horiguchi-san started this thread.
> 
> >+        ProcessClientWriteInterrupt(!port->noblock);
> ...
> >+/*
> >+ * ProcessClientWriteInterrupt() - Process interrupts specific to client writes
> >+ *
> >+ * This is called just after low-level writes. That might be after the read
> >+ * finished successfully, or it was interrupted via interrupt. 'blocked' tells
> >+ * us whether the
> >+ *
> >+ * Must preserve errno!
> >+ */
> >+void
> >+ProcessClientWriteInterrupt(bool blocked)
> 
> You're passing port->noblock as argument, but I thought the argument is
> supposed to mean whether the write would've blocked, i.e. if the write
> buffer was full.

Right.

> port->noblock doesn't mean that. But perhaps I misunderstood this -
> the comment on the 'blocked' argument above is a bit incomplete ;-).

The point here is that we tried the send() and then were interrupted
while waiting for the buffer to become writable. That pretty much
implies that the write buffer is full. The !port->noblock is because we
only are blocked on write if we're doinga blocking send, otherwise we'll
just return control to the caller...

I agree that this could use some more comments ;)

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Sawada Masahiko
Date:
Subject: Re: Proposal: knowing detail of config files via SQL
Next
From: Marc Mamin
Date:
Subject: Re: tablespaces inside $PGDATA considered harmful