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

[Mark Ellzey <mthomas@xxxxxxxxxx>]

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() says there is nothing to read. This is due
to the fact that your callback for new data is never called until
libevent gets around to processing the deferred queue.

Nick and I discussed why the while loop was needed, and concluded it was
not.

Please read the full explaination here:
https://github.com/nmathewson/Libevent/pull/33


> 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 layer (in the same way that
> EOFs normally stay queued in the kernel when bev_sock clients disable
> EV_READ).

This does not change any mechanics to openssl bufferevents without
deferred enabled. The logic is this:

SSL data was recv'd
_bufferevent_run_readcb() is called

That function does this:
228         if (p->options & BEV_OPT_DEFER_CALLBACKS) {
229                 p->readcb_pending = 1;
230                 if (!p->deferred.queued)
231                         SCHEDULE_DEFERRED(p);
232         } else {
233                 bufev->readcb(bufev, bufev->cbarg);
234         }

As you can see, if it is not deferred, it's not scheduled, your callback
is immediately called.

You can read why you would use a deferred here:
http://www.wangafu.net/~nickm/libevent-book/Ref6_bufferevent.html

I hope this fixed your problem?
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.