QThread + QtSqlの正しい方法

今日の記事に触発されて、データベースを別のスレッドに配置する方法を共有しました。 このメソッドは、データベースだけでなく、「一部のオブジェクトは別のストリームに住んでいるので、何かを尋ねてそれを使って何かをする必要がある」というパターンで説明されるやり取りにも適しています。 さらに、このメソッドは、タイプセーフで拡張可能であろうという点で優れています。文字列型のQMetaObject::invokeMethod()



、シグナルを介したストリームのQMetaObject::invokeMethod()



の結果の送信はありません。 直接関数呼び出しのみ、 QFuture



のみ！



免責事項：ここで与えられたコードは私の大きなプロジェクトの一部であるため、このプロジェクトの補助ライブラリ関数を使用します。 ただし、このような使用例を見逃さないようにし、それらのセマンティクスを説明します。



それでは、最も重要なことから始めましょう。別のスレッドでオブジェクトをどのように処理したいのでしょうか？ 理想的には、オブジェクトからメソッドをプルするだけで、メソッドはQFuture<T>



返します。その準備ができていることは、対応する非同期メソッドの実行が完了し、 T



ような結果になることを意味します



分解は私たちの友人であることを思い出してください。元のタスク「別のスレッドに何かをプルする必要があります」を検討して、その部分を「別のスレッドを保持し、 QFuture



returnでスレッドセーフな呼び出しを提供する必要がある」と考えてみQFuture



う。



この問題を次のように解決します：スレッド制御を担当するQThread



子孫QThread



には、メインスレッド（および他のスレッド）から呼び出されるScheduleImpl()



メソッドがあり、このファンクターをQFuture



でラップして必要なすべてを保存するファンクターを受け入れます。 QThread::run()



内で処理される特別なキューに移動します。



次のようなものが得られます。

 class WorkerThreadBase : public QThread { Q_OBJECT QMutex FunctionsMutex_; QList<std::function<void ()>> Functions_; public: using QThread::QThread; protected: void run () override; virtual void Initialize () = 0; virtual void Cleanup () = 0; template<typename F> QFuture<ResultOf_t<F ()>> ScheduleImpl (const F& func) { QFutureInterface<ResultOf_t<F ()>> iface; iface.reportStarted (); auto reporting = [func, iface] () mutable { ReportFutureResult (iface, func); }; { QMutexLocker locker { &FunctionsMutex_ }; Functions_ << reporting; } emit rotateFuncs (); return iface.future (); } private: void RotateFuncs (); signals: void rotateFuncs (); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、 ScheduleImpl()



は、タイプT ()



シグネチャを持つ特定のファンクターを受け入れ、 QFuture<T>



返し、ファンクターを特別な関数でラップし、返されたQFuture<T>



に関連付けられたシグネチャvoid ()



、およびこのファンクターに関連付けられvoid ()



QFuture<T>



それを準備完了としてマークし、このラッパーをキューに追加します



その後、信号rotateFuncs()



され、 run()



内でRotateFuncs()



メソッドに接続されます。このメソッドは、格納されているファンクターのラッパーのキューを処理するだけです。



run()



およびRotateFuncs()



メソッドの実装を見てみましょう。

 void WorkerThreadBase::run () { SlotClosure<NoDeletePolicy> rotator { [this] { RotateFuncs (); }, this, SIGNAL (rotateFuncs ()), nullptr }; Initialize (); QThread::run (); Cleanup (); } void WorkerThreadBase::RotateFuncs () { decltype (Functions_) funcs; { QMutexLocker locker { &FunctionsMutex_ }; using std::swap; swap (funcs, Functions_); } for (const auto& func : funcs) func (); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの関数はすべてシンプルです： rotateFuncs()



信号をrotateFuncs()



関数に接続します（うーん、命名スタイルにいくつのコメントがあるのでしょうか？）、ストリームオブジェクトの初期化関数を呼び出し、後継のどこかで定義し、ストリームをねじり始めます。 スレッドの所有者がスレッドに対してquit()



を行うと、 QThread::run()



が制御を返し、相続人はCleanup()



でそれをクリーンアップできます。



メインスレッドからrotateFuncs()



されたRotateFuncs()



がWorkerThreadBase



RotateFuncs()



をRotateFuncs()



ことを保証するのは、Qtのシグナルスロットメカニズムです。



ただし、 RotateFuncs()



、メインキューを一時的にブロックし、それ自体に移動した後、順次実行を開始します。



実際、それだけです。 使用例として、たとえば、IMクライアントのディスク上のアバター用のストレージシステムの一部を引用できます。







また、 AvatarsStorageOnDisk



の実装もあります。これは、Boost.Fusionを介したデータ構造の説明に従って、タブレット、SQLクエリ、および挿入/削除/更新用の対応する関数を生成できる、独自のORMフレームワークに関連する別の興味深いトピックです。 ただし、この実装は、特に元の問題の分解の観点から、一般に良いマルチスレッドの問題に特に関係していません。



そして最後に、提案されたソリューションの欠点に注意してください。

1. WorkerThreadBase
   
   
   
   後継WorkerThreadBase
   
   
   
   パブリックAPIで、別のスレッドにWorkerThreadBase
   
   
   
   れるオブジェクトで呼び出すすべてのメソッドを複製する必要があります。 この問題を効果的に解決する方法は、すぐには思いつきませんでした。
2. Initialize()
   
   
   
   およびCleanup()
   
   
   
   、何らかのRAIIに変換するように直接求められます。 このテーマについて何か考え出す価値はあります。