Interestingly, there was a long discussion over beer at a hackathon recently, about non-blocking and poll/select/kqueue/etc, in particular when mixed with TLS codepaths.
In my view, mixing poll()-style event loops with non-blocking descriptors will -- 99% of the time -- result in people writing broken event processing loops, and when they cannot figure out the breakage, they will double down repeatedly adding more and more hacks, and never solve the problem. We have seen poll loops with nested poll loops. I believe we should not encourage use of non-blocking mode. Actually, we should discourage non-blocking loops, by not providing APIs which encourage busy-loop polling. Non-blocking mode is poisonous. Kristaps Dzonsons <[email protected]> wrote: > Hi, > > I'm porting a nonblocking, polling OpenSSL system to libtls. However, > I'm not sure how this is non-hackily possible without SSL_pending(3) > to detect if less data is read with tls_read() than is buffered. > > writer: > tls_write(40) > > reader: > poll(POLLIN, INFTIM) -> POLLIN /* descriptor has a read */ > tls_read(20) /* 20 bytes read, 20 bytes remain */ > poll(POLLIN, INFTIM) -> 0 /* data was buffered */ > > This introduces tls_pending(3), which calls through to SSL_pending(3), > and includes a simple example in tls_read(3). > > Beck's tutorial says that "libtls is designed to do the common things > you do for making TLS connections easy", and I'm not sure my use case > meets that standard. If it looks reasonable, however, I can also add > the regression tests. > > Thank you, > > Kristaps
