Re: [Boost-users] Assigning to a boost::asio::ssl::context while asynchronous operations are using it

On Thu, 2019-09-26 at 04:27 +0500, Dmitrij V via Boost-users wrote:

move-assignment from what to where ?

The ssl context is context which tuned for incoming connections (if its server side). You can to have any number of ssl contexts for it (with ordered logic of that work), but I have just the one.

Without a code is hard to suggest what you doing, but the ssl context is not for moving, I have been storing it in server class, initialize it on start_server method, and put it into session_start for make connection with handshake etc (the ssl context forwarded for each connection as reference).

If you need more detailed answer, you could to give more details of your case.

2019-09-25 20:32 GMT+05:00, Martijn Otto via Boost-users :

...

I cannot find any definitive documentation on whether it's safe to move-assign to an ssl-context while it is used for asynchronous operations, assuming of course the application is single-threaded.

In my tests I could not trigger any failures, but that may be pure luck (or not lucky at all depending on point of view).

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

OK, I'll do my best to explain it as clearly as I can. In my main function I define an instance of an ssl context. This is then provided by lvalue reference to a 'server' class, which uses it to do a TLS handshake on each incoming connection. Now I want to be able to load a new certificate without restarting the process (minimizing downtime). For this I have implemented a signal handler listening to SIGUSR1. This handler constructs a new ssl context and then move-assigns it to the ssl context variable in the main function. Since the server class has a reference to this same object, it's also going to see the changes performed from the signal handler. The code is fully async, so there are no race-conditions in the classic sense of the word. The server may, however, be somewhere in the middle of performing a TLS handshake. I know that _after_ the handshake is complete, the ssl context is no longer relevant, but I can imagine this could break if the ssl context is move-assigned to when an asynchronous tls handshake is in progress. As I said, I could not manage to get this to fail in my tests, but conceptually I can imagine this is wrong. I'd like to be sure about this. If what I am doing is indeed not correct, I will need to use a shared_ptr so the handshakes can complete with the old context. Since this introduces overhead I'd like to do this only if really necessary.