Re: R: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function
От | Tom Lane |
---|---|
Тема | Re: R: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function |
Дата | |
Msg-id | 5744.1324483234@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | R: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function ("Andrea Grassi" <andreagrassi@sogeasoft.com>) |
Ответы |
R: R: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function
|
Список | pgsql-bugs |
"Andrea Grassi" <andreagrassi@sogeasoft.com> writes: > In internet I searched for detailed specifications of poll/select system > functions but I didn't understand one thing, that is which one of the 2 > statement is true: > 1) poll/select wait only for FUTURE modifications of ready-read state of > sockets > 2) poll/select check if there is something to read at the moment of the call > and otherwise wait for FUTURE modifications of ready-read state #1 is nonsense. If poll worked like that, it would be impossible for anyone to use it without suffering from race conditions. But if you don't see where exactly the poll() specification says so, I observe that it says first that poll sets the bit(s) if the requested condition is true, and second that *if* none of the events have occurred yet, poll should wait. See for instance http://pubs.opengroup.org/onlinepubs/007908799/xsh/poll.html regards, tom lane
В списке pgsql-bugs по дате отправления: