On Mon, Nov 14, 2011 at 07:13:39PM -0600, Mark Ellzey wrote:
>
> We cannot schedule or call the readcb UNTIL SSL_read() returns > 0 OR an
> error occurs on the socket.
I definitely feel confident this is the issue, going into that loop
provided ample time for SSL_read() to process an entire recor
On Mon, Nov 14, 2011 at 02:30:32PM -0800, Catalin Patulea wrote:
> This is actually causing an assert in my case :( The key is to get
> SSL_read to return both data (> 0) and EOF (= 0) within the same
> iteration of that (former) while loop. Then the flow looks like this:
>
> SSL_read() returns N
On Mon, Nov 14, 2011 at 11:17 AM, Mark Ellzey wrote:
> As far as I know, it doesn't. But I wrote this patch because if you are
> using a deferred bev with bulk incoming data, it never drops back into
> base_loop() until SSL_read() says there is nothing to read. This is due
> to the fact that your
On Mon, Nov 14, 2011 at 11:03:58AM -0800, Catalin Patulea wrote:
> Hi,
>
> Why does bev_ssl require deferred callbacks?
>
As far as I know, it doesn't. But I wrote this patch because if you are
using a deferred bev with bulk incoming data, it never drops back into
base_loop() until SSL_read() sa
Hi,
Why does bev_ssl require deferred callbacks?
Commit fc52dbac (see below) fixed an issue I was seeing where deferred
error_cb(EOF)s were confusing clients which had disabled EV_READs
(notably evhttp). If bev_ssl didn't require deferred cbs, the EOFs
would have stayed queued at the OpenSSL laye
