So, how is my first Adventure in Moveland going?
The solution for my classes went according to planned, which was nice. SessionHandle, being the class that holds
LIBSSH2_SESSION*, found itself suddenly surrounded by many new friends:
friend class SessionConnection;
friend class RemoteSessionHandle;
friend class SessionAuthenticator;
friend class RemoteChannelHandle;
SessionHandle::GetSession(), which provides access to said
LIBSSH2_SESSION*, went from public to private. And both SessionHandle and RemoteSessionHandle (which also gained SessionConnection as
friend) now have private
Reseat()functions, to allow SessionConnection to reseat the pointers on move:
SessionConnection::SessionConnection(SessionConnection&& other) :
port(move(other.port)), user(move(other.user)), pwd(move(other.pwd)),
remoteSessionHandle.Reseat(reportStatus, sock, sessionHandle);
So, everything went smoothly, right? Well, not quite. When I tested my move ctor, I was still getting a SegFault. It was now happening during the socket's dtor, more exactly here (boost's scoped_lock.hpp):
// Constructor acquires the lock.
So, it looked like I was still going to learn something more about Boost.Asio. I began tracing the socket's dtor. Here's boost::asio::basic_stream_socket's definition:
template <typename Protocol,
typename StreamSocketService = stream_socket_service<Protocol> >
: public basic_socket<Protocol, StreamSocketService>
Notice the stream_socket_service<>? Let's take a look at it (relevant info only):
template <typename Protocol>
: public boost::asio::io_service::service
: public boost::asio::detail::service_base<stream_socket_service<Protocol> >
// The type of the platform-specific implementation.
typedef detail::win_iocp_socket_service<Protocol> service_impl_type;
typedef detail::reactive_socket_service<Protocol> service_impl_type;
// The platform-specific implementation.
Since we're on Windows and have BOOST_ASIO_HAS_IOCP
#defined, let's take a look at win_iocp_socket_service:
template <typename Protocol>
class win_iocp_socket_service : public win_iocp_socket_service_base
There is actually little of interest here, so we move on to win_iocp_socket_service_base:
// Mutex to protect access to the linked list of implementations.
Holy Shmoly, Duck Dodgers! It has a mutex! And it's neither a reference nor a pointer!
So, what does it hold? In our case (Windows), it's an instance of boost::asio::detail::win_mutex, and it encapsulates an OS critical section object. And it performs RAII, too; win_mutex's dtor looks like this:
We can read here what
DeleteCriticalSection()does, but this is the important bit:
After a critical section object has been deleted, do not reference the object in any function that operates on critical sections (such as EnterCriticalSection, TryEnterCriticalSection, and LeaveCriticalSection) other than InitializeCriticalSection and InitializeCriticalSectionAndSpinCount. If you attempt to do so, memory corruption and other unexpected errors can occur.
Memory corruption and other unexpected errors? Check, eager young space cadet.
So, basically, even though Boost.Asio's socket is moveable (according to std::is_move_constructible<> and std::is_move_assignable<>), it may hold objects that aren't. In this case, we were left with two instances of win_iocp_socket_service_base, each with its instance of win_mutex that pointed to the same OS critical section object.
When the first socket ("moved to") is destroyed,
~win_mutex()is called, and the OS is told to get rid of that pesky critical section object pointed by
crit_section_. Which it dutifully does.
Then, the second socket ("moved from") is destroyed. During which, this is called:
// Remove implementation from linked list of all implementations.
Obviously, you can guess what
mutex_is holding, right? A lovely pointer to an ex-pesky ex-critical (and probably ex-)section. So when scoped_lock's ctor does this:
mutex_.lock(), this gets called:
Windows looks at it and says "Why, how quaint! Didn't you just tell me, a few nano-seconds ago, to get rid of this? You're probably having memory problems. But I've got just the thing to solve that. Here, have a SegFault! Oh, and a nice day, too, of course". Or, as the duck said "And brother, when it disintegrates, it disintegrates".
So, now what? Well, I've decided to apply to socket the same treatment I gave io_service, namely, it has gone from
Next time, the final part of this moving adventure - adding move semantics to the channel classes. And deciding whether I want to allow move when a command is executing.
That won't be the end of it, naturally. I'll have to make this thread-safe, and then I'll have to revisit all this. But, one step at a time.