> I haven't measured the performance difference, but I suspect it's > real. The filtering case involves another layer of buffering, > copying, and callbacks, and those typically matter. Then again, it > could be that crypto dominates the performance. In either case, > there's less machinery to go wrong in the non-filtering case.
OK, I'll stick to non-filtering for now. > If you're doing this in multithreaded mode, you might be running into > this issue: > > http://archives.seul.org/libevent/users/Feb-2012/msg00053.html I was indeed running in multi-threaded mode. However, I was running against libevent 2.0.16 which had a known bug with reads using filtering bufferevents. Upgrading to 2.0.17 fixed that problem. With non-filtering bufferevents, I seem to be hitting the issue you mention above :( > We'd sure like to fix it; any comments on that thread would be great! Will update the thread when I have some useful information to share. Perhaps looking at why the deadlock happens only with non-filtering bufferevents might give a clue? >> * When using a filtered bufferevent, should the filter be created >> AFTER the original bufferevent has successfully established >> connection? This works for me but if I create the filter immediately >> and then call bufferevent_socket_connect_hostname, I never get the >> event callback. > > Sounds like that could be a bug; are you calling connect on the filter > or the underlying bufferevent? I'm calling connect on the filter. Concretely, this does NOT work: underlying = bufferevent_socket_new(...); be = bufferevent_openssl_filter_new(..., underlying, ...); bufferevent_setcb(be, eventCb, ....); bufferevent_socket_connect_hostname(be, ...); I can see the remote end does receive a connection but the event callback never gets invoked. Instead, if I call connect on 'underlying' and then create 'be' in the event callback, that works. Of course, as soon as I create 'be', the event callback gets invoked a second time when the SSL handshake actually completes. Diwaker -- http://maginatics.com *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
