Using boost signals2 scoped_connection inside a handler

I was wondering if it is safe to use an assigned boost signals2 scoped_connection inside a handler to disconnect it. I know there is connect_extended but I keep some connections inside objects. Is it always safe to call disconnect inside handlers?

Yes. The extensive Thread Safety guarantees are documented here: https://www.boost.org/doc/libs/master/doc/html/signals2/thread-safety.html

It contains lots of reassuring statements like

Note that since we unlock the connection's mutex before executing its associated slot, it is possible a slot will still be executing after it has been disconnected by a connection::disconnect(), if the disconnect was called concurrently with signal invocation.

And

You may have noticed above that during signal invocation, the invocation only obtains handles to the signal's slot list and combiner while holding the signal's mutex. Thus concurrent signal invocations may still wind up accessing the same slot list and combiner concurrently. So what happens if the slot list is modified, for example by connecting a new slot, while a signal invocation is in progress concurrently? If the slot list is already in use, the signal performs a deep copy of the slot list before modifying it. Thus the a concurrent signal invocation will continue to use the old unmodified slot list, undisturbed by modifications made to the newly created deep copy of the slot list. Future signal invocations will receive a handle to the newly created deep copy of the slot list, and the old slot list will be destroyed once it is no longer in use. Similarly, if you change a signal's combiner with signal::set_combiner while a signal invocation is running concurrently, the concurrent signal invocation will continue to use the old combiner undisturbed, while future signal invocations will receive a handle to the new combiner.