On Mon, Aug 12, 2019 at 02:04:00PM -0700, Scott Dorr wrote: > As an addendum to that question: if I have an SSL connection with a > bufferevent, and I bufferevent_disable / bufferevent_free, can another thread > bufferevent_openssl_socket_new() using the original fd to create a new > bufferevent for that thread … without killing the underlying connection?
In general if you do not use BEV_OPT_CLOSE_ON_FREE this *may work*, *may* because SSL_* functions will be called twice (i.e. SSL_clear()/SSL_do_handshake()), but even taking this into account, I wouldn't recommend going this way, since this: - can be broken in future - may not work always, and will introduce hard to debug issues > I don’t mind a disable/base_set/enable if that’ll work with a bufferevent > originally created via bufferevent_openssl_socket_new(), and that would be > the easiest thing for me to do here, but if that doesn’t work, is the above > (disable/free … other thread creates an explicitly new bufferevent) doable > without killing the established connection underneath? > > On Aug 12, 2019, at 1:03 PM, Scott Dorr <[email protected]> wrote: > > > > So, not possible for bufferevent_openssl_socket_new()? Right now - no, but it is pretty easy to archive. But you can check this debug tree: https://github.com/azat/libevent bufferevent_base_set (this should work, but should be verified/covered) Regards, Azat. *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
