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 majord...@freehaven.net with unsubscribe libevent-users in the body.
