Re: [Libevent-users] Re: Avoid potential SSL read spinlocks

[Catalin Patulea <catalinp@xxxxxxxxxx>]

A few things I forgot to mention:

Re: bev_ssl needing deferred or not, without OPT_DEFER_CALLBACKS,
https-client does not work for me. I haven't investigated.

Re: SSL_read loops. Consider the following scenario:

- Peer sends two (small) SSL records in a row (perhaps in the same TCP segment)
- fd becomes readable, libevent delivers read_cb to bev_ssl
- bev_ssl calls SSL_read only once - does this read process only the
first record or both?

If it only processes the first record, then we should call SSL_read
again. But the fd is no longer readable, so libevent won't dispatch
read_cb. The second second record is queued somewhere above BIO but
below SSL_read, and we get stuck.

But just to emphasize - this entirely depends on (AFAICT undocumented)
internal behaviour of SSL_read. If this were read(2) then the fd would
remain readable from poll() so we would get a second read_cb, emptying
the kernel queue.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.