ClientCursor instances are currently responsible for registering themselves on construction and detecting when they've been killed in destruction to avoid attempting to deregister them from the cursor manager.

void ClientCursor::init() {
    invariant(_cursorManager);

    ...

    _cursorid = _cursorManager->registerCursor(this);

    ...
}

ClientCursor::~ClientCursor() {
    ...

    if (_cursorManager) {
        // this could be null if kill() was killed
        _cursorManager->deregisterCursor(this);
    }

    ...
}

We may want to take inspiration from the API of the ClusterCursorManager in mongos for refactoring the interface of CursorManager in mongod. One behavior of the existing CursorManager that we likely want to preserve is how the "killCursors" command calls CursorManager::eraseCursor() and is guaranteed to have released the state for that cursor after the response is returned. This differs from how ClusterCursorManager::killCursor() calls ClusterCursorManager::setKillPending() and only releases the state for that cursor after the ClusterCursorCleanupJob processes it.