> From: Eran Borovik [mailto:eran.borovik@xxxxxxxxx] > Sent: Wednesday, January 29, 2020 07:32 Please respond to the list rather than directly to me, since the subject may be of interest to other readers. I'm including the list in this response. > The only thing that still confuses me is that if I am reading the docs > correctly, SSL_read may return SSL_WANT_WRITE and SSL_write may return > SSL_WANT_READ even when they don't encounter a blocking condition, but > because of negotiation. Right. > Now, I use edge triggered polling with Epoll (EPOLLET), which means > that if SSL_read/write decides to give me an WANT* status when the > socket doesn't have a blocking condition, then epoll will never wake > and I am stuck (unless I understand that this is the case and retry > immediately). Is there a way to actually understand that there is a > blocking condition in the socket from OpenSSL or do I need to use > select with zero timeout to realize what is the correct condition of > the socket after each time SSL gives me SSL_WANT*? Yes, I think you need to test for readability / writability at some point. You can do that immediately when you get a WANT_*, or you can have your epoll time out periodically and test then if you have pending I/O. Personally, I'm leery of edge-triggered activation for this reason. It's too easy to miss some race condition or other case where you might end up blocked forever. I'd always have epoll time out so you can do a level-poll of all sockets that have pending operations; that turns a failure mode into one that simply has suboptimal performance, at a small resource cost. -- Michael Wojcik Distinguished Engineer, Micro Focus
