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  ("Andrea Grassi" <andreagrassi@sogeasoft.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH v2] Use CC atomic builtins as a fallback
Следующее
От: cmjnov92@gmail.com
Дата:
Сообщение: BUG #6349: Cannot install on 32 bit platform