2016-05-24 5 views
0

私はboost :: signals2を使用しており、接続管理の問題があります。 scoped_connectionsを後で整理されたリストに格納しています。しかし、関連するシグナルを所有するオブジェクトが破壊された場合、scoped_connection :: disconnect()はそのフィールドのいくつかが現在無効であるため中止されることが分かりました。signals2 :: 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()を実行するとプリフェッチやデータのアボートに終わります。

私はこの問題を解決するために見落としている何かがsignals2 APIにありますか?または、私の接続管理を再考する必要がありますか?この時点でクライアントの信号への接続を維持することは奇妙に思えますが、クライアントが消費するストリームが範囲外になる可能性があります。この場合、マネージャのスロットをクライアントから切断する必要があります。

答えて

0

これはオブジェクトライフタイムの問題で、信号2の問題ではないことが判明しました。スコープ付き接続への生ポインタを使用して、コピー不可のプロパティを取得しました。しかし、私が見落としたことは、構造体がリストに挿入されるときに構造体が構築されると、元のデータは破棄され、ポインタのメモリが削除されるということです...

共有ポインタに変更するとこの問題が修正されました。

関連する問題