Python-> Cython-> C ++、さらにCOM：自動テスト用のフレームワークの作成

誰もが自動テストの利点を知っていると思います。 これらは、大幅な変更があってもコードの動作を維持するのに役立ちます。 また、面倒な手作業からテスターを救うことができ、より興味深いタイプのテストに集中することができます。



私たちのプロジェクトの個々の部分は25年以上前のものであるという事実にもかかわらず、私たちは自動テストを導入する道のまさに始まりに過ぎません。 それにもかかわらず、すでにいくつかの成功を収めています。これについては、この記事で説明します。



適切な自動テストの書き方は、別の記事のトピックです。 そしておそらくそうではありません。 個々のコンポーネントのテストをどのように実装したかを説明します。 コンポーネントはC ++で記述されており、COMと非常によく似たインターフェースを備えています。 テストの言語として、Pythonを選択し、非常に強力なPyTestテストフレームワークを使用しました。 この記事では、C ++ / COMバンドルとPythonバンドルの複雑さ、遭遇した落とし穴、およびこれらの問題を解決する方法について説明します。

免責事項

• NDAのため、プロジェクトのコードをコピーアンドペーストすることはできません。 したがって、この記事のすべての例はゼロから作成されており、決してコンパイルされていません。 したがって、軽微な不正確さ、構文エラー、またはコード設計規則の不遵守が存在する場合があります。 しかし、私は主な意味を伝えようとしました。
• 私はpythonの専門家ではありません。 実を言うと、プロジェクトの途中でpythonを教え始めました。 したがって、Pythonに関するいくつかのステートメントは、完全に真実ではないか、完全に解決されていない可能性があります。
• 例のPythonコードは、pep8に対応していない可能性があります。 多くの場合、SOMプロトタイプを反映し、そのスタイルを取り入れています。
• この記事はcythonのマニュアルではありません。多くのものが舞台裏に残されています。

背景

私が取り組んでいるプロジェクトでは、大規模で複雑なモジュールを開発しています。 数百万行のC ++コード、12個の大きなコンポーネント、100個のdllが内部にあります。 このモジュールは、いくつかの巨大なアプリケーションで使用されています。



歴史的に、すべてはUIを介してのみテストされ、ほとんどの部分は手動でテストされていました。 1つの領域の変更が、まったく別の場所のどこかにバグを発見することがよくあります。 そして、彼らはこのバグを数日、あるいは数週間後にさえ発見します。 また、別の製品がモジュールの新しいバージョンを統合することを決定した数か月後に何かがポップアップすることがあります。



コミット時にCIを追跡する単体テストがあります。 しかし、TDDについて話し始めたとき、コードは15年以上も前のものでした。 コードはモノリシックで、個別に実行するだけでは機能しません。 多くのリファクタリングが必要であり、誰もリソースを提供しません。 したがって、単純な関数または個別のクラスの単体テストのみがあります。



ただし、モジュールにはAPIがあるため、このAPIを使用してこのモジュールをテストできます。 当社を使用するすべてのアプリケーションのユーザーケースを収集し、これに関する自動テストを作成できます。 その後、コミット時にCIでこれらのテストを直接実行できます。 そのため、コンポーネントテストのアイデアが生まれました。



しかし、誰がテストを書くのでしょうか？ テスターは優れたテストスクリプトを考え出し、テストデータを準備できますが、テスターはC ++を知りません（そして知っている人はすぐに開発者に捨てられます）。 プログラマーはそのようなテストをコーディングできますが、通常、いくつかの肯定的なシナリオに対しては十分なファンタジーしかありません。 すべての否定的なケースをカバーするには、通常忍耐だけでは十分ではありません。



隣のチームの同僚の経験から学ぶことにしました。 コンポーネントのサイバーラッパーを作成し、テストに使用する単純なインターフェイスをPythonで設定しました。 Pythonを入力するためのしきい値は、C ++よりもはるかに低くなっています。 テスターは数日で簡単にpythonを習得でき、優れた自動テストの作成を開始できます。

COMはそれと何の関係がありますか？

あなたが私たちの苦しみを説明し始める前に、私たちのインターフェースについていくつかの言葉を言う必要があります。 私たちは、COMを組み合わせてLinux、ポピー、フライに移植したテクノロジーを使用しています。 レジストリの欠如に関連するインフラストラクチャの違いがいくつかありますが、これはこの記事にとって重要ではありません。



COMのような技術は、既製のプラグインコンポーネントインフラストラクチャのような多くの利点を提供します。 異なる国の異なるチームが作成したモジュール（サードパーティのプラグインを含む）を簡単にドッキングできます。 同時に、異なるコンパイラ、ランタイム、および標準ライブラリ間の互換性の問題について心配する必要はありません。 また、すべてのモジュールのインターフェースの文体、パラメーターと戻り値の転送に関する合意、オブジェクトの存続期間-これらはすべて、COMと同様の合意によって規制されています。



裏返しがあります。 モジュール内では、最新のC ++標準のバンを使用できます。 しかし、パブリックインターフェイスでは、COMのルールを遵守する必要があります。単純型またはIUnknown後継インターフェイスのみです。 STLはありません。 実行なし、HRESULTのみ。 このため、モジュールの境界にあるコードは非常に面倒で読みにくいです。

シトンの最初の経験

まず、モジュールの12個のインターフェイスを特定しました。これにより、小規模ながら完全なワークフローを実装できます。



しかし、これらのインターフェイスはパブリックAPIの一部ですが、実際には非常に低レベルです。 特定の操作を行うために、単一の関数またはメソッドを取得して呼び出すことはできません。 5つのオブジェクトを作成し、それらを相互に接続し、それらを実行して、将来の結果を待つ必要があります。 この完全な複雑さは、トランザクション、非同期、Undo / Redoを整理し、スレッドセーフな内部へのアクセスやその他のことを整理するために必要です。 つまり、COMスタイルのC ++コードの2画面。



同僚の推奨に従い、低レベルのインターフェイスを隠す小さなレイヤーを作成することにしました。 Pythonでは、いくつかの高レベル関数を公開することが提案されました。



cythonラッパーは、c ++で呼び出しを単純に転送しました。

cdef class MyModuleObject(): cdef CMyModuleObject * thisptr # wrapped C++ object def __init__(self): self.thisptr = new CMyModuleObject() def __dealloc__(self): del self.thisptr def DoSomething1(self): self.thisptr.DoSomething1() def DoSomething2(self): self.thisptr.DoSomething2() def GetResult(self): return self.thisptr.GetResult()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CMyModuleObjectクラスのC ++実装はすでに有用なことを行っています。モジュールのオブジェクトを作成し、それらにいくつかの有用なメソッド（同じ2つのコード画面）を呼び出します。



Cythonは本質的に翻訳者です。 上記のソースコードに基づいて、cythonは大量のコードを生成します。 dll / soとしてコンパイルする（そしてpydに名前を変更する）と、Pythonモジュールが取得されます。 CMyModuleObjectのC ++実装もこのdllに配置する必要があります。 これで、Pythonモジュールをpythonからインポートできるようになりました（最初にインポートパスで反転しました）。 通常のPythonインタープリターを使用して起動できます。主なことは、アーキテクチャが一致することです。 インポート行を実行することにより、pythonはdll自体を取得し、必要なものをすべて初期化してインポートします。



Pythonスクリプトは次のようになりました。

 from my_module import * obj1 = MyModuleObject() obj1.DoSomething1() obj1.DoSomething2() print obj1.GetResult()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

かっこいい！ C ++よりもはるかに簡単です！



最初の段階では、テストフレームワークに煩わされるのではなく、最初に通常のスクリプトを使用してアプローチを実行することにしました。 この形式では、すでに何かを書くことができますが、このアプローチは柔軟性に違いはありませんでした。 レイヤー内の何かを変更する必要がある場合は、C ++でコードを変更する必要がありました。

COMインターフェイスのスニッフィング

私は、低レベルのインターフェイスを直接スニッフィングして、必要に応じてPythonでレイヤーを作成しようとすることを主張しました。 このアイデアは、1対1のインターフェースをいびき、公開APIのレベルでテストできるという上司に販売されました。



すぐに言ってやった。 私たちはすぐにそのような計画に到達しました。 PythonオブジェクトのコンストラクターはCOMオブジェクトを作成し、それへのリンクを所有します。 もちろん、リンクはCComPtrのスマートコピーコピーと見なされます。

 cdef class PyComponent: cdef CComPtr[IComponent] thisptr def __cinit__(self): # Get the COM host cdef CComPtr[IComHost] com_host result = GetCOMHost(IID_IComHost, <IUnknown**>&(com_host)) hresultcheck (result) # Create an instance of the component result = com_host.inArg().CoCreateInstance( CLSID_Component, NULL, IID_IComponent, <void**>self.thisptr.outArg() ) hresultcheck( result ) def SomeMethodWithParam(self, param): result = self.thisptr.inArg().SomeMethodWithParam(param) hresultcheck (result) def GetStringFromComponent(self): cdef char [1024] buf result = self.thisptr.inArg().GetStringFromComponent(buf, sizeof(buf)-1) hresultcheck(result) return string (buf)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通常、HRESULT関数は興味深いものではありません。 機能が成功した場合-まあ、いい。 フロッピーを使用する場合は、さらに先へ進む必要はないでしょう。 したがって、エラーコードを確認し、Python例外をスローするだけです。 戻りコードの処理は、クライアントのPythonコードのレベルでは実行されません。これにより、クライアントコードが大幅にコンパクトになり、読みやすくなります。

 class HRESULT_EXCEPTION(Exception): def __init__(self, result): super(HRESULT_EXCEPTION, self).__init__("Exception code: " + str(hex(result & 0xffffffff))) cpdef hresultcheck(HRESULT result): if result != S_OK: raise HRESULT_EXCEPTION(result)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

hresultcheck関数はcpdefとして宣言されていることに注意してください。 これは、ネイティブなものだけでなく、Pythonのもの（Pythonではhresultがまだチェックされていることもある）として呼び出すことができることを意味します。 2番目のプロパティは、sitonによって生成されるエラー処理コードを大幅に削減し、実行を高速化します。 SUCCEEDEDマクロ呼び出しをマスターしていないので、S_OKと比較します-今のところ、それで十分です。



それにもかかわらず、特定のインターフェースとそのメソッドを特定の方法でのみ使用し、他の何も使用しないことが明らかな場合、1対1のラッピングから離れることもありました。 たとえば、COMオブジェクトが空で作成され、その後パラメーターがSet *（）メソッドを介して、または何らかのInitialize（）を呼び出すことでそれに詰め込まれると想定される場合、この場合はPythonレベルでパラメーターを使用して便利なコンストラクターを実行します。



または、別の例を示します。 あるオブジェクトへのリクエストは、概念的に別のオブジェクト（または単に新しいオブジェクト）へのリンクを返すことがあります。 COMでは出力パラメーターを使用する必要がありますが、Pythonではオブジェクトを人間が返すことができます。

 cdef class Class2: cdef CComPtr[IClass2] thisptr cdef class Class1: cdef CComPtr[IClass1] thisptr def GetClass2 (self): class2 = Class2() result = self.thisptr.inArg().GetClass2( class2.thisptr.outArg() ) hresultcheck ( result ) return class2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

カプセル化の観点から見ると、コードはあまり良くありません-あるオブジェクトが別のオブジェクトの腸に侵入します。 しかし、カプセル化（より正確にはプライバシー）を備えたpythonでは、あまり良くありません。 しかし、私たちはまだもっと美しい方法を思いついていません。 誰かがクライアントコードに手を入れてClass2を作成しようとするリスクがありますが、おそらくそれでは何も得られないでしょう。 誰かがPythonのプライベートコンストラクタのオプションを教えてくれたら嬉しいです。



上記のコード例は、pyx拡張子を持つファイルにあります（ちなみに、それらをすべて1つにまとめるのではなく、多くのことを実行できます）。 プロのcppのようなものです-実装ファイルです。 しかし、シトンでは、まだ宣言を持つファイルが必要です-pxd-sishnyとみなされるすべての名前が記述される場所。

 from libcpp cimport bool from libcpp.vector cimport vector from libcpp.string cimport string from libc.stdlib cimport malloc, free cdef extern from "mytypes.h": ctypedef unsigned short int myUInt16 ctypedef unsigned long int myUInt32 ctypedef myUInt32 HRESULT ctypedef struct GUID: pass ctypedef enum myBool: kMyFalse kMyTrue kMyBool_Max cdef extern from "hresult.h": cdef HRESULT S_OK cdef HRESULT S_FALSE cdef extern from "Iunknown.h": cdef cppclass IUnknown: HRESULT QueryInterface (const IID & iid, void ** ppOut) HRESULT AddRef () HRESULT Release () cdef extern from "CComPtr.h": cdef cppclass CComPtr [T]: # this is trick, to assign pointer into wrapper T& assign "operator="(T*) T* inArg() T** outArg() cdef extern from "comhost.h": cdef extern IID IID_IComHost cdef cppclass IComHost(IUnknown): HRESULT CoCreateInstance ( const GUID& classid, IUnknown* pUnkOuter, const IID& iid, void** x )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CComPtr :: operator =（）に注意してください。 sitonコードでCComPtrに直接割り当てようとすると、何も機能しません。 彼は単にこの構文構造を適切に解析できません。 私はキャラクターの名前を変更するトリックに頼らなければなりませんでした。 割り当ては、キャラクターがシトンでどのように見えるかであり、引用符では、コードで呼び出す必要があるものを正確に設定します。



このトリックは、syslogと同じ方法でPythonクラスまたは関数を呼び出す必要がある場合に役立ちます。



pxd：

 cdef extern from "MyFunc.h": int CMyFunc "MyFunc" ()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

pyx：

 def MyFunc(): CMyFunc()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロジェクトに戻ります。 Pythonコードはさらにシンプルでコンパクトですが、ほとんどのユーザーにとっては低レベルです。 したがって、私たちはまだレイヤーを残して、Pythonで書き直すことにしました。 その結果、これらの2ページのかさばるCOMコードはこれになりました

 def do_operation(param1, param2): operation = DoSomethingOperation(param1, param2) engine = TransactionEngine() future = engine.Submit(operation) future.Wait() return future.GetResult()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、コードははるかにコンパクトで理解しやすくなり、do_operation（）などの高レベルインターフェイスを使用し、必要に応じて「インターフェイス」インターフェイスに移動することができました。



柔軟性の感覚があり、毎回C ++部分を再コンパイルする必要はありませんでした。 さらに、最初は10個のインターフェイスのみをスニッフィングする必要があり、その後の各機能では1〜2個のみをスヌーズする必要がありました。

問題が始まる

この形式では、このテクノロジーはすでにほとんどのプロジェクトに適しているかもしれませんが、いくつかの基本的な制限に直面しました。



したがって、COMホスト（COMインフラストラクチャ、あらゆる種類のCoCreateInstanceなどを提供するオブジェクト）は、通常のプラスオブジェクトです。 そのため、誰かがそれを作成（CoInitialize analog）してから削除（CoFinalize）する必要があります。 しかし、ここに問題があります。Pythonモジュールにはmain（）がありません。 いずれにしても、必要な形で。



したがって、ポジティブアプリケーションオブジェクトを作成し、このオブジェクトにホストの初期化/ファイナライズを配置しました。 彼らは、Pythonからこのオブジェクトを（各スクリプトの最初に）作成できるようにするラッパーを作成しました。



しかし、非常に迅速に、出口でクラッシュを発見し始めました。 C ++（最初に作成されたオブジェクトは最後に削除されます）とは異なり、Pythonでのオブジェクトの破壊順序は定義されていません。 まあ、いずれにしても、彼に影響を与える方法はありません。 ムーンフェーズに応じて、Pythonは最初にApplicationオブジェクトを釘付けにし、COMインフラストラクチャを消滅させ、すべてのコンポーネントを強制的にアンロードしました。 その後、PythonはSOMオブジェクトへのリンクを持つ他のオブジェクトを削除しました。 すでにアンロードされたdllからRelease（）を呼び出そうとすると、クラッシュしました。



2番目の問題は、実行可能ファイルの場所です。 大規模なコンポーネントには、実行可能ファイルを基準とした何らかのパスに沿ってデータを含むファイルを開こうとする場所がたくさんあることがわかりました。 最終的なアプリケーションが何らかの既知の方法でシステムにインストールされている場合、これは正常です。 これは、作業ディレクトリでコンパイルされたアプリケーションで作業している場合も正常です。 しかし、実行可能ファイルがシステムディレクトリで突然pythonになった場合、このメソッドは機能しなくなります。



アプリケーションディレクトリを再定義できる機能もありました。 これはほとんどの場合に機能しました。 しかし、残念なことに、この再定義を無視して、実行可能ファイルに対する相対パスを独自に計算し続けた自転車ビルダーがいました。 それを受け取って修正するのは正しいことですが、かなりの労力が必要になります。 これはまだ未処理のままであると判断しました。



最後に、3番目の問題はイベントループです。 実際、このモジュールは非常に複雑でインタラクティブです。 これは、単なる「関数の呼び出し-結果の取得」スタイルライブラリではありません。 これは巨大な収穫機です。 内部では、なんとかメッセージを交換する数百のスレッドを回転させます。 コードの中には中生代の間に書かれたものがあり、メインスレッドでのみ実行されることを意図しています（それ以外では動作しません）。 他の場所では、メッセージはハードコードによってメインスレッドに送信され、そこにこのメッセージの処理方法を知っていることが期待されます。 また、独自のストリームとメッセージのサブシステムもあります。これは、メッセージ処理サイクルがメインストリームで確実にスピンし、これをすべて実行することを意味します。 それなしでは仕方ありません。



最初の最も簡単な解決策は、アプリケーションクラスにrun_event_loop（）メソッドを挿入し、メッセージループをねじることでした。 有用な作業が完了すると、プロセスは停止しました（現在理解しているように、これは偶然の一致によって発生していました:)）



一般に、このようなスクリプトは正常に機能しました。ノンブロッキング関数（終了を待たない）を使用して作業を開始し、その後イベントループに向かいます。

 app = Application() start_some_processing_async() app.run_event_loop()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、いくつかの双方向性を必要とするシナリオでは、問題が判明しました。 たとえば、作業を開始できず、数秒後に停止しようとしました。 実際、メインスレッドのメッセージ処理サイクルが開始されるまで、作業は開始されませんでした。 サイクルが開始した場合、Pythonには戻りません。



もちろん、Pythonレベルで非同期の何かをフェンスすることも可能ですが、これは明らかに私たちが望むものではありません。 結局のところ、このアプローチは、非同期システムに誘惑されていない人々をプッシュすることになっていた。 彼らはそのように書いて、イベントループでスチームバスを浴びたくない

 start_some_processing_async() time.sleep(3) cancel_processing()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

考え直すことなく、別のスレッドで処理を開始し、メインでメッセージループをひねりました。 しかし、すぐに次の問題に遭遇しました-GIL（Global Interpreter Lock） 。 Pythonicスレッドは実際には並行して実行されていないことが判明しました。 一度に実行されるスレッドは1つだけであり、スレッドは100コマンドごとに切り替えられます。 このすべてがこの同じGILを規制し、1つを除くすべてのスレッドを停止します。



メインスレッドがapp.run_event_loop（）関数に行って戻ってこなかった場合（および設計上、ハングする必要がある場合）、他のスレッドの他のPythonコマンドは実行されないことが判明しました。 メインスレッドにこれ以上100個のコマンドがなかったことだけで、インタープリターは切り替えるには早すぎると判断しました。



解決策はnogil sitonキーワードで見つかりました。 nogilとマークされたコードは、最初にGILを解放してから、システムを呼び出します。 最後に、GILが再びキャプチャされます。 T.O. メインスレッドはGILを解放し、メッセージループに入りました。 2番目のスレッドが制御を取り、必要なすべてを行いました。

 def Func(self): result = 0 cdef IComponent * component = self.thisptr.inArg() with nogil: result = component.Func() hresultcheck(result)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ちなみに、シトンは非常に不機嫌なものです。 Pythonコードと1行のコードに干渉できるとは限りません。 また、一部のPython構造体を呼び出したり、nogilセクションで新しい変数を作成したりすることもできません（論理的には、これにはGILによって保護されているPythonの腸へのアクセスが必要です）。 変数を正しく宣言し、必要な呼び出しを行うには、このように倒さなければなりません。



すべてが機能し始めたように見えましたが、非常に不安定です。 私たちは絶えずある種のクラッシュとハングをキャッチし、アイドル機能につまずきました（ファイルは相対パスで開かれませんでしたが、誰もエラーを投げませんでした）。

他の方法で設計する

数週間、これらの3つの問題を解決し、さまざまなアプローチを試みました。 しかし、毎回別の解決できない問題がありました。 GILは何よりも配信しましたが、COMホストのアンロードを無効にする方法がわかりませんでした。



luaにジャンプすることさえ考えましたが、制限のいくつかはまだ残っています。 この場合にのみ、最初からすべてを実行する必要があります。



しかし、その後、大胆なアイデアが浮上しました。 しかし、pythonからsyshコードではなく、syshからpythonを実行するとどうなりますか？ 次のことを行うアプリケーションを作成します。

• COMホストの初期化
• 2番目のスレッドを開始する
• メインスレッドで、イベントループを実行する
• 2番目のスレッドで、Pythonインタープリターを実行します（他のアプリケーションに埋め込むための対応するAPIがあります）

このアプローチは、3つの問題すべてを一挙に解決します。

1. COMホストのライフタイムを制御し、Pythonストリームが処理を終了した後、その破壊を保証できます。
2. テストアプリケーションはメイン製品の隣に配置されます。つまり、すべての相対パスが機能します。
3. 最後に、GILに問題はありません。 Pythonはシングルスレッドスクリプトを実行します。つまり、リソースを誰とも共有する必要はありません。

知ってる？ このアプローチはうまくいきました！ しかし、最終的に解決されたいくつかの小さな問題がありました

• メインスレッドでいくつかの呼び出しを行う必要があります。 まあ、何も、私たちはメッセージをメインスレッドに引き込み、何が必要かを尋ねました。
• PYTHON_HOMEとPYTHON_PATHのインストールにかなり手を加える必要がありました。 重要な点は、Python関数Py_SetPythonHome（）も標準のsetenv（）も渡された文字列をそれ自体にコピーするのではなく、単にポインターを覚えていることです。 私たちの場合、それは一時変数へのポインタでした。
• Pythonのバージョンに依存しないようにするために、すべてのガッツを持ち歩くことにしました。 標準ライブラリ（判明したように、zipから直接読み取ります）といくつかの追加ライブラリを含む

私がいじくり回さなければならなかった別の問題は、sys.exit（）関数でした。 unittestからの戻りコードをキャッチして出力に渡し、CIで処理するために必要でした。



このように動作します。 スクリプト内の誰かがsys.exit（）を呼び出すと、SystemExit例外が実際にスローされます。 この例外はPython自身によってキャッチされ、グローバルにキャッチされる他の例外と同様に、スタックトレースとともにコンソールに出力する必要があります。 しかし、Py_PrintEx関数はそのような特別なケースがあることを知っており、SystemExit例外を出力するように提案された場合、exit（）を呼び出す必要があります。



はい、そうです！ Printという関数は、exit（）呼び出しを行います。 そして、この出口は正直に実現します-アプリケーション全体を取得して削減します。 そして彼は、アプリケーションに未リリースのハンドル、不完全なストリーム、閉じられていないファイル、最終化されていないモジュール、100万のアクティブなスレッド、そしてすべてのジャズがあるという事実を吐き出したかったのです。



しかし、python（どんな場合でも2.7.6。ジャンク、私は知っています）は、これがAPIレベルで課税することを許可しません。 pythonソースからプロジェクトにいくつかの関数をコピーし（PyRun_SimpleFileExFlags（）とそれが呼び出すいくつかのプライベートな関数から）、自分でそれを終了する必要がありました。 そのため、SystemExitの場合のバージョンは正しく終了し、リターンコードを返します。 T.O. python部分の完了後のテストアプリケーションは、それ自体を正しくきれいにして消すことができます。



最初は2人のデザイナーがいました。1人は組み込みのpythonを使用してテストアプリケーションを作成し、2人目は以前のようにpythonのロード可能なモジュールを作成しました。 しかし、後ですべてを1人のデザイナーに結合しました。 テストアプリケーションはpythonを初期化した後、Pythonモジュール（sitonによって生成された）の初期化関数を呼び出しました。 T.O. 既に開始時のpythonは既にモジュールを知っていました（インポートはまだ行われていなければなりませんでした）。

コールバック

このフォームでは、テストアプリケーションが非常に優れていることがわかりました。 テストフレームワーク（標準ユニットテスト）を台無しにして、テスターは少しずつテストを書き始めました。 その間、私たち自身がインターフェースをラップし続けました。



別の機能を台無しにしてしまったため、場合によってはコールバックを受け入れる必要があるという事実に出会いました。 つまり Pythonは関数を同期的に呼び出し、その腸でPythonへのコールバックを引き起こします。



plusインターフェースは次のようになります。

 class ICallback : public IUnknown { virtual HRESULT CallbackFunc() = 0; }; Class IComponent : public IUnknown { virtual HRESULT MethodWithCallback(ICallback * cb) = 0; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Pythonクラスは、ソースの下のplusインターフェイスから継承できません。 したがって、プロジェクトのシステム部分では、Pythonに呼び出しを転送する独自の実装を作成する必要がありました。



.h

 //Forward declaration struct _object; typedef struct _object PyObject; class CCallback : public ICallback { //COM stuff ... CCallback * Create(); // ICallback virtual HRESULT CallbackFunc(); public: void SetPythonCallbackObject(PyObject * callback_handler); private: PyObject * m_pPythonCallbackObject; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.cpp

 const char PythonMethodName[] = "PythonCallbackMethod"; void CCallback::SetPythonCallbackObject(PyObject * callback_handler) { // Do not addref to avoid cyclic dependency m_pPythonCallbackObject = callback_handler; } HRESULT CCallback::CallbackFunc() { if(!m_pPythonCallbackObject) return S_OK; // Acquire GIL PyGILState_STATE gstate = PyGILState_Ensure(); if ( gstate == PyGILState_UNLOCKED ) { // Call the python method char * methodName = const_cast<char *>(PythonMethodName); //Py_Api doesn't work with constant char * PyObject * ret = PyObject_CallMethod(m_pPythonCallbackObject, methodName, NULL); if (!ret) { if (PyErr_Occurred()) { PyErr_Print(); } std::cout<<"cannot call"<<PythonMethodName<<std::endl; } else Py_DecRef(ret); } // Release the GIL PyGILState_Release(gstate); return S_OK; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードの特別な瞬間は、GILのキャプチャです。 そうでない場合、せいぜい、PythonはGILがキャプチャされていることを確認すると壊れますが、ほとんどの場合、ハングするかミスをします。



コンソールアプリケーションがあるため、コンソールへのエラー出力です。 Pythonコードが例外をスローした場合でも、ハンドラーは例外をキャッチしてトレースバックを出力します。



シトンの側面からは、次のようになります。

 cdef class PyCallback (object): cdef CComPtr[ICallback] callback def __cinit__(self): self.callback.assign( CCallback.Create() ) self.callback.inArg().SetPythonCallbackObject(<PyObject *> self) def PythonCallbackMethod(self): print "PythonCallbackMethod called" cdef class Component: cdef CComPtr[IComponent] thisptr def __cinit__(self): // Create IComponent instance ... def CallMethodWithCallback(self, PyCallback callback): cdef IComponent * component = self.thisptr.inArg() cdef ICallback * cb = callback.callback.inArg() hresult = 0 with nogil: hresult = component.MethodWithCallback(cb) hresultcheck(hresult)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

MethodWithCallback() GIL, .

 component = Component() callback = PyCallback() component.CallMethodWithCallback(callback)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, . , API, cython.



, . , , . , GIL ( , ), . PyGILState_Ensure() , , , .



, , , . , , , . .



. , , . PyRun_FileExFlags(), , PyArena_Free()

  PyThreadState *_save = PyEval_SaveThread(); while (GetCurrentlyActiveCallbacks() > 0) ; // semicolon here is correct PyEval_RestoreThread(_save);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに

python->cython->C++ API . , . . , – .



, . ++/ . .



PyTest . ! , .



, . , , , - . .



. cython' . .



Cython . , , . .



. , . – :

 PyRun_InteractiveLoop(stdin, "<stdin>");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

++ IDE. , CI . ++ . . , — PyTest .



, . . , .



, , - .