Re: [patch] helps fe-connect.c handle -EINTR more gracefully

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [patch] helps fe-connect.c handle -EINTR more gracefully
Дата
Msg-id 29744.1004145109@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [patch] helps fe-connect.c handle -EINTR more gracefully  (David Ford <david@blue-labs.org>)
Список pgsql-hackers
David Ford <david@blue-labs.org> writes:
> [ much ]

I think you are missing the point.  I am not saying that we shouldn't
deal with EINTR; rather I am raising what I think is a legitimate
question: *what* is the most appropriate response?  My reading of
HP's gloss suggests that we could treat EINTR the same as EINPROGRESS,
ie, consider the connect() to have succeeded and move on to the
wait-for-connection-complete-or-failure-using-select() phase.
If that works I would prefer it to repeating the connect() call,
primarily because it avoids any possibility of introducing an
infinite loop.

For PQrequestCancel we clearly do need to retry the connect(), since
that use of connect() isn't nonblocking.  But I'm not convinced that
we should do so in the main-line connection code.

> It is possible with the current code for the 
> connection to fail in non-blocking mode.  Reason: you call connect() in 
> non-blocking mode, break out of the section on EINPROGRESS, and continue 
> assuming that the connection will be successful.

No, we don't.  If you think that, then you haven't studied the code
sufficiently to be submitting patches for it.  What we actually do
is exactly what is recommended by the manpage you're quoting at me.
It's just split across multiple routines.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Lamar Owen
Дата:
Сообщение: Re: 7.2b1 ...
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: 7.2b1 ...