Question

我正在使用boost :: signals2并且存在连接管理问题。我将scoped_connections存储在稍后修剪的列表中。但是，我发现如果拥有相关信号的对象已被破坏，scoped_connection :: disconnect（）将中止，因为它的几个字段现在都是无效的。

signals2::connection conn =
    client->connectRequest( RequestSignal::slot_type(
        bind( &Manager::requestRefresh, this, _1 ) ).track( client ) );
mClients.push_back( ClientConnection( client, conn ) );

ClientConnection：

struct ClientConnection
{
    weak_ptr<Client> client;
    signals2::scoped_connection* connection;

    ClientConnection( weak_ptr<Client> aClient, signals2::connection aConnection )
    {
        client = aClient;
        connection = new signals2::scoped_connection( aConnection );
    }

    ~ClientConnection()
    {
        delete connection;
    }
}

Manager类拥有这些ClientConnections的列表，并定期迭代并尝试删除无法向客户端获取合法shared_ptr的条目。我现在已经知道，当对象到期时，track（）不会像我想象的那样断开连接;它只是阻止信号发射。当客户端超出范围时，scoped_connection最终指向一堆坏内存，并在执行disconnect（）时最终导致预取或数据中止。

我忽略了signal2 API中的哪些内容可以纠正这个问题？或者我是否必须重新考虑我的连接管理？我知道从这一端开始保持与客户端信号的连接似乎很奇怪，但是客户端消耗的流可能超出范围，所以在这种情况下我需要断开Manager的插槽与客户端的连接。 / p>

Answer 1

事实证明这是一个对象生命周期问题，而不是signal2问题。我使用了一个指向scoped连接的原始指针来绕过它的noncopyable属性。但我忽略的是，当结构被复制时，它被插入到列表中，原始文件被销毁，这会删除指针的内存...

将其更改为共享指针可解决此问题。

如何防止signals2 :: scoped_connection在disconnect（）中中止？

1 个答案: