<div dir="ltr">Hi,<div>Excellent, so I think I am finally understanding this correctly. And yes, we do have epoll timeouts to clean up all sort of missed race conditions and bugs (either in kernel or user mode).<div>For performance reasons, EDGE trigger is a must for my application.<br><div>What if instead of using select to understand the socket status (big hammer), I will simple retry the call?</div></div><div>For example, if SSL_read returns WANT_*, I do another SSL_read. On the low chance that this is a negotiation, there will be forward progress and I am fine. If not, I know that the socket is blocked.</div><div>It is too bad that I cannot differentiate between the two states without going to kernel space. I wish there were some way by just querying SSL. I see that there is a family of SSL_want* methods. Can these be of use?</div></div><div><br></div><div>Regards,</div><div>Eran.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 29, 2020 at 6:12 PM Michael Wojcik <<a href="mailto:Michael.Wojcik@microfocus.com">Michael.Wojcik@microfocus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> From: Eran Borovik [mailto:<a href="mailto:eran.borovik@gmail.com" target="_blank">eran.borovik@gmail.com</a>]<br>
> Sent: Wednesday, January 29, 2020 07:32<br>
<br>
Please respond to the list rather than directly to me, since the subject<br>
may be of interest to other readers. I'm including the list in this<br>
response.<br>
<br>
> The only thing that still confuses me is that if I am reading the docs<br>
> correctly,  SSL_read may return SSL_WANT_WRITE and SSL_write may return<br>
> SSL_WANT_READ even when they don't encounter a blocking condition, but<br>
> because of negotiation.<br>
<br>
Right.<br>
<br>
> Now, I use edge triggered polling with Epoll (EPOLLET), which means<br>
> that if SSL_read/write decides to give me an WANT* status when the<br>
> socket doesn't have a blocking condition, then epoll will never wake<br>
> and I am stuck (unless I understand that this is the case and retry<br>
> immediately). Is there a way to actually understand that there is a<br>
> blocking condition in the socket from OpenSSL or do I need to use<br>
> select with zero timeout to realize what is the correct condition of<br>
> the socket after each time SSL gives me SSL_WANT*?<br>
<br>
Yes, I think you need to test for readability / writability at some<br>
point. You can do that immediately when you get a WANT_*, or you can<br>
have your epoll time out periodically and test then if you have<br>
pending I/O.<br>
<br>
Personally, I'm leery of edge-triggered activation for this reason.<br>
It's too easy to miss some race condition or other case where you<br>
might end up blocked forever. I'd always have epoll time out so you<br>
can do a level-poll of all sockets that have pending operations;<br>
that turns a failure mode into one that simply has suboptimal<br>
performance, at a small resource cost.<br>
<br>
--<br>
Michael Wojcik<br>
Distinguished Engineer, Micro Focus<br>
<br>
<br>
</blockquote></div>