From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Nikolai Zhubr <n-a-zhubr(at)yandex(dot)ru> |
Cc: | PG-General Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Nonblocking libpq + openssl = ? |
Date: | 2016-09-16 23:05:07 |
Message-ID: | 20160916230507.negltf5z5wskgzqi@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Nikolai Zhubr | 2016-09-17 00:12:53 | Re: Nonblocking libpq + openssl = ? |
Previous Message | Nikolai Zhubr | 2016-09-16 22:21:37 | Nonblocking libpq + openssl = ? |