> Subject: is p*s*Socket..
Oops...
At Thu, 9 Feb 2023 17:32:08 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in
>
>
> On 2023/02/09 11:50, Kyotaro Horiguchi wrote:
> > Hello.
> > While looking a patch, I found that pqSocketPoll passes through the
> > result from poll(2) to the caller and throws away revents. If I
> > understand it correctly, poll() *doesn't* return -1 nor errno by the
> > reason it has set POLLERR, POLLHUP, POLLNVAL, and POLLRDHUP for some
> > of the target sockets, and returns 0 unless poll() itself failed to
> > work.
>
> As far as I understand correctly, poll() returns >0 if "revents"
> has either of those bits, not 0 nor -1.
Right. as my understanding.
If any of the sockets is in any of the states, pqSocketPoll returns a
positive, which makes pqSocketCheck return 1. Finally
pqRead/WriteReady return "ready" even though the connection socket is
in an error state. Actually that behavior doesn't harm since the
succeeding actual read/write will "properly" fail. However, once we
use this function to simply check the socket is sound without doing an
actual read/write, that behavior starts giving a harm by the false
answer.
> You're thinking that pqSocketPoll() should check "revents" and
> return -1 if either of those bits is set?
In short, yes.
pqSocketPoll() should somehow inform callers about that
state. Fortunately pqSocketPoll is a private function thus we can
refactor the function so that it can do that properly.
If no one object to that change, I'll work on that.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center