Re: [Libevent-users] OpenSSL-based bufferevents

[Diwaker Gupta <diwaker@xxxxxxxxxxxxxx>]

> 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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.