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 bytes into an iov from evbuffer_reserve_space -
> no run_read_cb yet
> SSL_read() returns 0, which leads into conn_closed(), which queues a
> error_cb(EOF)
> Back in do_read, a read_cb is queued
Not entirely true:
int err = SSL_get_error(bev_ssl->ssl, r);
print_err(err);
switch (err) {
case SSL_ERROR_WANT_READ:
/* Can't read until underlying has more data. */
if (bev_ssl->read_blocked_on_write)
if (clear_rbow(bev_ssl) < 0)
return -1;
break;
case SSL_ERROR_WANT_WRITE:
/* This read operation requires a write, and the
* underlying is full */
if (!bev_ssl->read_blocked_on_write)
if (set_rbow(bev_ssl) < 0)
return -1;
break;
default:
conn_closed(bev_ssl, err, r);
break;
WANT_READ will trigger when a full record hasn't been processed; My
brain isn't working right now, but it looks as if set_rbow() does the
right thing and waits for the whole record to be read. BUT, I think I
see the issue you trying to explain.
In one sentence - I think this is the problem:
We cannot schedule or call the readcb UNTIL SSL_read() returns > 0 OR an
error occurs on the socket.
Right?
***********************************************************************
To unsubscribe, send an e-mail to majord...@freehaven.net with
unsubscribe libevent-users in the body.
