🔸 🏯 🚙 C ++でPHPモジュールを開発しています。パート1：Zend Engine 2の世界への遠足 👨‍🌾 🥔 👦

こんにちは、Harbasコミュニティの皆さん！

猫の下には、さまざまなソース（ほとんどが英語）から入手したC ++を使用してPHPの拡張機能を作成し、自分のニーズに合わせて1つのモジュールを開発しながらZend Engine 2のソースを選択する情報がいくつか記載されています。そのボリュームが十分に大きいので、簡潔にしようとしました。

この部分では：

しかし、この部分ではC ++には到達しません... =）

小さな免責事項：記事の内容は、最初は真実ではなく、公式文書に基づいているわけではありません（それはありますか？）そして、ZE 2に対する主観的な見解でもあります。開発の初期段階で時間を節約するため。

Zend Engine 2の内部世界

基本的なデータ型

Zend Engine 2はCで記述されています。これは、内部エコシステムに大きな影響を与えています。クラスオブジェクトのパラダイムが存在しない場合、グローバル変数、自由関数、およびユーザー定義データ型（構造体）との類似性がZE 2内に発生しました。すべての場合において、単純データ型と複合データ型の組み合わせ、およびそれらを処理するための手順があります。

最も一般的な構造はzval （zend-value？）です。構造は、 ユーザースペースの裏側のPHP変数の表現です（ここおよび今後、ユーザースペースはPHPで記述されたコードを意味し、ZEが処理するため、 ユーザースペースの裏側はCコードです）。

PHPは、弱い動的型付けと自動メモリ管理を備えた言語です。この言語の変数は、ライフサイクル全体で型を変更でき、必要がなくなった後にプログラマが明示的に削除する必要はありません（ガベージコレクタがこれを処理します）。これらの気まぐれについては、部分的に膨らませてzvalする必要があります。現在（ PHP 5.3.3 ）この構造は次のように定義されています（zend.h）：

typedef struct _zval_struct zval; struct _zval_struct { /* Variable information */ zvalue_value value; /* value */ zend_uint refcount__gc; zend_uchar type; /* active type */ zend_uchar is_ref__gc; };

ここで何が見えますか？驚くべきことに、Zend値（zval）は直接変数の値ではありません。変数の値は値フィールドに格納され、そのタイプはzvalue_value （下）です。 valueに格納される値のタイプは、タイプフィールドによって決定され、次のいずれか（zend.h）になります。

  #define IS_NULL 0 #define IS_LONG 1 #define IS_DOUBLE 2 #define IS_BOOL 3 #define IS_ARRAY 4 #define IS_OBJECT 5 #define IS_STRING 6 #define IS_RESOURCE 7 #define IS_CONSTANT 8 #define IS_CONSTANT_ARRAY 9

ええ、ここにあります-これらは非常に8種類のPHPデータで、多くの場合、人々はインタビューにリストできません！さらに、2つの個別の値、IS_CONSTANTおよびIS_CONSTANT_ARRAY。

構造には、この変数への参照の数に関する情報（refcount__gc）と、この変数が参照であるかどうかを決定するフラグ（is_ref__gc）も含まれます。この情報は、ZE内のメモリを使用して効果的な作業を整理するために必要です。たとえば、ユーザー空間での次の状況：

 <?php $foo = 5; // 1 $bar = $foo; // 2

タイプIS_LONGのzval valオブジェクトの作成（ユーザー空間のすべての整数はユーザー空間の反対側のC longに対応）を作成し、そのis_ref_gcを0に、refcount_gcを1（最初の行）に設定し、文字「foo」 val）を値として持つ現在のプロセス文字テーブル（実際には変数名とその値の連想配列） 2行目では、zvalの新しいインスタンスは作成されません。シンボルテーブルに追加されたばかりのValは1参照カウント増加し、バーシンボルは同じvalでシンボルテーブルに登録されます。これにより、新しい変数を作成するために必要なメモリ割り当ての数が削減されます。

インタープリターがコードに遭遇すると：

 ... $bar = '42';

彼は、シンボル「bar」に対応するプロセスzvalの文字の現在のテーブルから抽出し、まず、この値へのリンクの数をチェックします。それが1より大きく、zvalが参照（is_ref_gc == 0）でない場合、インタープリターは$ barの現在の値のコピーを作成し、それでアクションを実行し（この場合、文字列値を '42'と同等にします）、シンボルテーブルに「bar」を入れます新しい価値。 refcoun_gc == 1またはis_ref_gc == 1の場合、アクションはシンボルテーブルから取得した値に対して直接実行されます。したがって、次のような状況（むしろ人為的であるが、生命に対する権利がある）の状況では：

 <?php $foo = 100500; //1 $bar = $foo; //2 echo $bar; unset($bar); $foo = '42'; //3

インタープリターのコストはzvalを1つだけですが、それに対応する2文字です。これは、コメント1の行でzval valが1に等しいリンクの数で作成されるため可能です。コメント2の行では、値valの新しいシンボル「バー」が登録されます。そのため、refcoun_gcはすでに2に等しいコメント3では、unset（$ bar）を呼び出した後、valへのリンクの数が再び1に減少するため、新しいzvalは作成されません。

ユーザー空間で$ b =＆$ aの形式の構造が検出された場合、is_ref_gcが1に等しくなると推測することは難しくありません。

上記のアプローチは、「書き込み時に分離」と呼ばれます。

次に、タイプを見てみましょう zvalue_value（zend.h）：

 typedef union _zvalue_value { long lval; /* long value */ double dval; /* double value */ struct { char *val; int len; } str; HashTable *ht; /* hash table value */ zend_object_value obj; } zvalue_value;

これが組合であることに気付くのは難しくない。これは、zvalue_value型の変数のアドレスのメモリにあるデータは、開発段階と実行段階の両方で、ユニオンを構成するデータ型のいずれかとしてプログラマーにとって便利な方法で解釈できることを意味します。このzvalue_valueの機能により、PHPユーザー空間変数のタイプを一生簡単に変更できるようになります（zval変数の現在のタイプは、そのタイプフィールドを参照することで見つけることができます）。

ただし、ここには5つの一意のフィールドとデータ型8のみが表示されていると言えます。PHP型のzvalue_valueユニオンへのマッピングは次のとおりです。

long lval-整数（整数）、ブール（ブール）およびリソース（リソース）
double dval-ここでは明確です（double）
struct ... str-PHP文字列（文字列）
HashTable * ht-配列（配列）
zend_object_value obj-PHPオブジェクト（オブジェクト）-SPLとカスタムの両方。
null-値には値がありません（zval.type == IS_NULL）。

zvalue_valueの構造を検討することから何が役立つでしょうか？

リソースタイプは整数の識別子でのみ表されるため、ユーザースペースではダークホースのように見えます。ユーザー空間の反対側では、そのような識別子を開いているファイル記述子、TCPソケット、データベース接続オブジェクトなどに関連付けることができます。マッピングは、リソースの特別なストレージを介して行われます（もちろん、C側）。
PHPの実際のものはすべて倍精度で、8バイトを占有します。
原則として、文字列はバイナリセーフにすることができます。内部でヌル文字を使用します。これは、文字列の長さが、この文字列が置かれているメモリへのポインタとともに格納されるという事実により実現されます。 strlen操作はユーザー空間で高速です。行末のヌル文字はオプションです。実際、多くの拡張機能は正確にnullで終了する文字列を使用し、文字列strlenを軽視しません。
配列は、内部HashTable型で表されます。 HashTableは別の構造ですが、それを検討し、それを操作する原則はこの記事の範囲外です。
PHPのオブジェクトは、 zend_object_value構造で表されます。拡張機能の開発は、独自のデータ型の作成と関連しているため、後で説明します。
PHPで変数を作成すると、変数のタイプに関係なく、32ビットアーキテクチャで少なくとも16バイトが消費されます（ユニオンのサイズがその中のフィールドの最大サイズに等しい場合、zvalフィールドのサイズを合計します）。

それでオブジェクトに到達しました。 zend_object_value構造体は、オブジェクトを含むユーザー空間変数を表すことを目的としています。そして、クラスオブジェクトパラダイムのオブジェクトとは何ですか？オブジェクトとは、データとその処理方法の共生です。それでは、構造を見てみましょう zend_object_value （zend_type.h）：

 typedef unsigned int zend_object_handle; typedef struct _zend_object_handlers zend_object_handlers; typedef struct _zend_object_value { zend_object_handle handle; zend_object_handlers *handlers; } zend_object_value;

構造は、整数識別子（ハンドル）と別の構造（zend_object_handlers *ハンドラー）の組み合わせであり、オブジェクトに関連付けられた特定のイベントが発生したときにZE 2エンジンによって呼び出される関数へのポインターが含まれます。そのようなイベントには、新しい変数をオブジェクトを含む変数の値と同等にする（zend_object_add_ref_t add_ref）、スコープから出る、別の値で初期化する、またはオブジェクトを含む変数の設定解除を呼び出す（zend_object_del_ref_t del_ref）、__ clone（zend_object_cloneを呼び出すことによりオブジェクトを複製する）が含まれますclone_obj）、オブジェクトプロパティへのアクセス（zend_object_read_property_t read_property）、オブジェクトプロパティへの書き込み（zend_object_write_property_t write_property）など zend_object_handlers構造体自体は次のとおりです（zend_object_handlers.h）：

 struct _zend_object_handlers { /* general object functions */ zend_object_add_ref_t add_ref; zend_object_del_ref_t del_ref; zend_object_clone_obj_t clone_obj; /* individual object functions */ zend_object_read_property_t read_property; zend_object_write_property_t write_property; zend_object_read_dimension_t read_dimension; zend_object_write_dimension_t write_dimension; zend_object_get_property_ptr_ptr_t get_property_ptr_ptr; zend_object_get_t get; zend_object_set_t set; zend_object_has_property_t has_property; zend_object_unset_property_t unset_property; zend_object_has_dimension_t has_dimension; zend_object_unset_dimension_t unset_dimension; zend_object_get_properties_t get_properties; zend_object_get_method_t get_method; zend_object_call_method_t call_method; zend_object_get_constructor_t get_constructor; zend_object_get_class_entry_t get_class_entry; zend_object_get_class_name_t get_class_name; zend_object_compare_t compare_objects; zend_object_cast_t cast_object; zend_object_count_elements_t count_elements; zend_object_get_debug_info_t get_debug_info; zend_object_get_closure_t get_closure; };

そして、ここで詳細を読んでください。

気を取られて、zend_object_valueに戻ります。それで、イベントの関数ハンドラへのポインタ以外に何が含まれていますか？しかし、何も！ _zend_object_handlers内のオブジェクトの動作を決定しようとする試みの類似性を見た場合、何らかの奇妙な識別子（ハンドル）に加えて、特定のインスタンスに固有のデータは観察されません。しかし、識別子自体（真空中の球体）は意味がありません。したがって、同種のエンティティの何らかの種類のリポジトリが存在する必要があります。この識別子は、あるエンティティを別のエンティティから区別します。

ZEのこのようなストレージはZend Object Storageです。その中のキーはオブジェクト記述子（zend_object_value.handle）と値です...はい、はい、おそらくあなたはそれを推測しました-別の種類の構造はzend_object （zend.h）です：

 typedef struct _zend_object { zend_class_entry *ce; HashTable *properties; HashTable *guards; /* protects from __get/__set ... recursion */ } zend_object;

ここでは、別々のピースから、油絵がすでに形になり始めています。 HashTable *プロパティ-特定のインスタンスに固有のデータを保持できる場所です。プロパティフィールドはZEの連想配列標準であり、そのキーは現在のオブジェクトのクラスのフィールド名でなければならず、値はこのオブジェクトのフィールド（プロパティ）の現在の値です。

そのため、現時点ではオブジェクトを操作するための次のオプションがあります-特定の状況でオブジェクトの標準動作を再定義でき（zend_object_handlersの対応する関数をオーバーライドすることにより）、HashTable *に関連付けられたプロパティをインスタンスフィールドに書き込むことでデータを格納できます現在のオブジェクト。何かが欠けています...ああ、そうですが、どのようにオブジェクトにカスタム動作を追加しますか（新しいメソッドを作成します）？メソッドは1つのクラスのすべてのオブジェクトに共通するものであるため、クラスのすべてのオブジェクトに対する共有アクセスへの共有アクセスを何らかの構造に配置することは論理的です。そのような構造は、 zend_class_entry （zend.h）です。

 struct _zend_class_entry { char type; char *name; zend_uint name_length; struct _zend_class_entry *parent; int refcount; zend_bool constants_updated; zend_uint ce_flags; HashTable function_table; HashTable default_properties; HashTable properties_info; HashTable default_static_members; HashTable *static_members; HashTable constants_table; const struct _zend_function_entry *builtin_functions; //  union _zend_function *constructor; //,    union _zend_function *destructor; //    union _zend_function *clone; union _zend_function *__get; union _zend_function *__set; union _zend_function *__unset; union _zend_function *__isset; union _zend_function *__call; union _zend_function *__callstatic; union _zend_function *__tostring; union _zend_function *serialize_func; union _zend_function *unserialize_func; zend_class_iterator_funcs iterator_funcs; /* handlers */ zend_object_value (*create_object)(zend_class_entry *class_type TSRMLS_DC); zend_object_iterator *(*get_iterator)(zend_class_entry *ce, zval *object, int by_ref TSRMLS_DC); int (*interface_gets_implemented)(zend_class_entry *iface, zend_class_entry *class_type TSRMLS_DC); /* a class implements this interface */ union _zend_function *(*get_static_method)(zend_class_entry *ce, char* method, int method_len TSRMLS_DC); /* serializer callbacks */ int (*serialize)(zval *object, unsigned char **buffer, zend_uint *buf_len, zend_serialize_data *data TSRMLS_DC); int (*unserialize)(zval **object, zend_class_entry *ce, const unsigned char *buf, zend_uint buf_len, zend_unserialize_data *data TSRMLS_DC); zend_class_entry **interfaces; zend_uint num_interfaces; char *filename; zend_uint line_start; zend_uint line_end; char *doc_comment; zend_uint doc_comment_len; struct _zend_module_entry *module; };

zend_class_entry構造体の目的は、同じクラスのすべてのオブジェクトの一般的な側面を表すことです。 zend_class_entryは、実際にはクラスそのものです。ご覧のとおり、構造は小さくなく、各フィールドの目的を考慮することはこの記事のタスクではありません。コメントでマークしたフィールドに注目しましょう。

const struct _zend_function_entry * builtin_functions-_zend_function_entry構造の配列へのポインター。これらが将来のクラスのメソッドであると推測することは難しくありません。 const修飾子でマークされているため、この配列の要素を変更する（つまり、インスタンス化されたクラスオブジェクトのメソッドをオーバーライドする）ことはできません（zend_object_value.handlersとは異なります）。

コンストラクターからunserialize_funcまでのフィールドはPHPのマジックメソッドです（unserialize_funcが__wakeupであり、serialize_funcが__sleepであると推測するのは難しくありません。残りのメソッドも同様のニーモニックを持っています）。

独自の拡張機能を作成する過程で、builtin_functionsにエントリを追加したり、将来のクラスのマジックメソッドを再定義したりできます。

最後になりましたが、このZE構造の魅力的な世界への遠足のヒーローは、拡張モジュール自体の表現に関与する構造です-zend_module_entry （zend_modules.h）：

 struct _zend_module_entry { unsigned short size; unsigned int zend_api; unsigned char zend_debug; unsigned char zts; const struct _zend_ini_entry *ini_entry; const struct _zend_module_dep *deps; const char *name; const struct _zend_function_entry *functions; int (*module_startup_func)(INIT_FUNC_ARGS); int (*module_shutdown_func)(SHUTDOWN_FUNC_ARGS); int (*request_startup_func)(INIT_FUNC_ARGS); int (*request_shutdown_func)(SHUTDOWN_FUNC_ARGS); void (*info_func)(ZEND_MODULE_INFO_FUNC_ARGS); const char *version; size_t globals_size; #ifdef ZTS ts_rsrc_id* globals_id_ptr; #else void* globals_ptr; #endif void (*globals_ctor)(void *global TSRMLS_DC); void (*globals_dtor)(void *global TSRMLS_DC); int (*post_deactivate_func)(void); int module_started; unsigned char type; void *handle; int module_number; char *build_id; };

一般的な場合、拡張機能は1つではなく複数のクラスを同時に実装できます-エクスポート関数のみ（ライトはOOPに収束しませんでした）、上記の構造の設計にどのように影響するかを考慮してください：

const struct _zend_function_entry * functions-拡張機能によってエクスポートされた関数の配列へのポインター。 zend_class_entry.builtin_functionsと同様です。
int（* module_startup_func）（INIT_FUNC_ARGS）-拡張機能が接続されたときに呼び出される関数へのポインター。特に、拡張機能がクラスをエクスポートする場合、この関数でクラスをZE 2の内部クラスレジストリに登録する必要があります。
int（* module_shutdown_func）（SHUTDOWN_FUNC_ARGS）-拡張機能がアンロードされるときに呼び出される関数へのポインター。ここで自分自身を拭かなければなりません。

データ型の階層

前の段落では、通常のzvalから一般的なzend_module_entryへのパスを調べました。これらの型を巧みに処理して、独自のPHP拡張機能を作成し、オブジェクトを生成するための適切に調整されたファクトリを編成できます。実際、PHP拡張モジュールはユーザースペースのトレーニングスクールのようなものです。最初に、それをビルド（PHP_MINIT_FUNCTIONを呼び出し）し、特定の焦点を持つ人材派遣会社として労働取引所（PHP_MINIT_FUNCTIONでエクスポートされたクラスまたは関数を宣言）に登録し、次に、従業員（クラスの新しいインスタンス）の最初の要求時に、戦闘機を準備するサイクルを開始する（作成する）必要がありますオブジェクト）。準備は、作成されたオブジェクトにメモリを割り当て、特定のイベントハンドラー（zend_object_handlers）および独自のクラス（zend_class_entry）に関連付けます。これには、未来のオブジェクトのメソッドが含まれます。この準備は通常、関数extension_name_objects_newに配置され、フィールドzend_class_entry.create_objectに関連付けられます。

概略的に、展開構造は次のように表すことができます。

また、拡張機能のデータ型の階層をより明確に想像するために、次の図を示します。

おわりに

この記事には多くのテキストと非常に少ないコードが含まれていましたが、ZE 2データ型の世界への遠足がなければ、特定の関数の呼び出しの目的を理解しようとすることは非常に困難です。次のパートでは、PHP拡張モジュールを作成するために必要な最初の手順について説明しますが、その前にzvalの操作とメモリ割り当ての管理のトピックに触れます。

PS興味のある人のための記事の素晴らしい選択はこちらです。

C ++でPHPモジュールを開発しています。 パート1：Zend Engine 2の世界への遠足

Zend Engine 2の内部世界

基本的なデータ型

データ型の階層

おわりに

More articles:

C ++でPHPモジュールを開発しています。パート1：Zend Engine 2の世界への遠足