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?
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? Thanks! - soctt > On Aug 12, 2019, at 1:03 PM, Scott Dorr <[email protected]> wrote: > > So, not possible for bufferevent_openssl_socket_new()? > > > - scott > > >> On Aug 8, 2019, at 12:51 AM, Azat Khuzhin <[email protected]> wrote: >> >> On Tue, Aug 6, 2019 at 2:41 AM Scott Dorr <[email protected]> wrote: >>> >>> ThreadA receives a new connection and creates a new bufferevent to handle >>> the IO. Sometime later, it needs to hand responsibility for that connection >>> off to another thread. >>> >>> Can ThreadA use something like bufferevent_base_set to ‘move’ that >>> bufferevent to the other thread (ThreadB) so that callbacks associated with >>> it are triggered in ThreadB’s context? >> >> bufferevent_base_set() will work but with a few caveats: >> - will *work* only for plain bufferevent sock (created with >> bufferevent_socket_new()) >> - will *fail* if you already enables some events (EV_READ/...), hence >> you need to buffevent_disable/bufferevent_base_set/bufferevent_enable >> sequence >> >> Regards, >> Azat. >> *********************************************************************** >> To unsubscribe, send an e-mail to [email protected] with >> unsubscribe libevent-users in the body. > *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
