Re: Nonblocking libpq + openssl = ?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Nonblocking libpq + openssl = ?
Дата
Msg-id 20160916230507.negltf5z5wskgzqi@alap3.anarazel.de
обсуждение исходный текст
Ответ на Nonblocking libpq + openssl = ?  (Nikolai Zhubr <n-a-zhubr@yandex.ru>)
Ответы Re: Nonblocking libpq + openssl = ?  (Nikolai Zhubr <n-a-zhubr@yandex.ru>)
Список pgsql-general
Hi,

> So going PQconsumeInput()->pqReadData()->pqsecure_read()->pgtls_read() in a
> supposedly non-blocking operation we finally come to a tight busy-loop
> waiting for SSL_ERROR_WANT_WRITE to go down! How could such thing ever be,
>
> - with no even sleep(1),
> - no timeout,
> - no diagnostics of any sort,
> - a comment implying that getting stuck in a (potentially) infinite
> sleepless loop deep inside a library is OK.

> And looking more into this pgtls_read() function it seems it just has
> inadequate interface. So that it has really no way to reliably indicate some
> important details to its caller, namely the need to wait for
> write-readyness. It's like if ssl support was a quick-n-dirty hack rather
> than a consistently integrated feature. Or do I read it all wrong?
> Any thoughts?

Well, it's not pretty. I quite dislike this bit, and I've complained
about it before.  But it is noteworthy that it's nearly impossible to
hit these days, due to ssl-renegotiation support having been ripped out.
That's what could trigger openssl to require writes upon reads.

Greetings,

Andres Freund


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

Предыдущее
От: Nikolai Zhubr
Дата:
Сообщение: Nonblocking libpq + openssl = ?
Следующее
От: Nikolai Zhubr
Дата:
Сообщение: Re: Nonblocking libpq + openssl = ?