> Subject: is p*s*Socket.. Oops...
At Thu, 9 Feb 2023 17:32:08 +0900, Fujii Masao <masao.fu...@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