Re: Assigning to a boost::asio::ssl::context while asynchronous operations are using it

From: Martijn Otto (boost_at_[hidden])
Date: 2019-09-26 06:52:43

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
> <boost-users_at_[hidden]>:
> > 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_at_[hidden]
> 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.