<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                企業??AI智能體構建引擎,智能編排和調試,一鍵部署,支持知識庫和私有化部署方案 廣告
                前一小節介紹了PHP的生命周期,在其生命周期的各個階段,一些與服務相關的操作都是通過SAPI接口實現。這些內置實現的物理位置在PHP源碼的SAPI目錄。這個目錄存放了PHP對各個服務器抽象層的代碼,例如命令行程序的實現,Apache的mod_php模塊實現以及fastcgi的實現等等。 在各個服務器抽象層之間遵守著相同的約定,這里我們稱之為SAPI接口。每個SAPI實現都是一個_sapi_module_struct結構體變量。(SAPI接口)。在PHP的源碼中,當需要調用服務器相關信息時,全部通過SAPI接口中對應方法調用實現,而這對應的方法在各個服務器抽象層實現時都會有各自的實現。 > 由于很多操作的通用性,有很大一部分的接口方法使用的是默認方法。 如圖2.4所示,為SAPI的簡單示意圖。 ![圖2.4 SAPI的簡單示意圖](http://box.kancloud.cn/2015-07-06_559a632a5b9e1.png) 圖2.4 SAPI的簡單示意圖 以cgi模式和apache2服務器為例,它們的啟動方法如下: cgi_sapi_module.startup(&cgi_sapi_module) // cgi模式 cgi/cgi_main.c文件 ? apache2_sapi_module.startup(&apache2_sapi_module); // apache2服務器 apache2handler/sapi_apache2.c文件 這里的cgi_sapi_module是sapi_module_struct結構體的靜態變量。它的startup方法指向php_cgi_startup函數指針。在這個結構體中除了startup函數指針,還有許多其它方法或字段。其部分定義如下: struct _sapi_module_struct { char *name; // 名字(標識用) char *pretty_name; // 更好理解的名字(自己翻譯的) ? int (*startup)(struct _sapi_module_struct *sapi_module); // 啟動函數 int (*shutdown)(struct _sapi_module_struct *sapi_module); // 關閉方法 ? int (*activate)(TSRMLS_D); // 激活 int (*deactivate)(TSRMLS_D); // 停用 ? int (*ub_write)(const char *str, unsigned int str_length TSRMLS_DC); // 不緩存的寫操作(unbuffered write) void (*flush)(void *server_context); // flush struct stat *(*get_stat)(TSRMLS_D); // get uid char *(*getenv)(char *name, size_t name_len TSRMLS_DC); // getenv ? void (*sapi_error)(int type, const char *error_msg, ...); /* error handler */ ? int (*header_handler)(sapi_header_struct *sapi_header, sapi_header_op_enum op, sapi_headers_struct *sapi_headers TSRMLS_DC); /* header handler */ ? /* send headers handler */ int (*send_headers)(sapi_headers_struct *sapi_headers TSRMLS_DC); ? void (*send_header)(sapi_header_struct *sapi_header, void *server_context TSRMLS_DC); /* send header handler */ ? int (*read_post)(char *buffer, uint count_bytes TSRMLS_DC); /* read POST data */ char *(*read_cookies)(TSRMLS_D); /* read Cookies */ ? /* register server variables */ void (*register_server_variables)(zval *track_vars_array TSRMLS_DC); ? void (*log_message)(char *message); /* Log message */ time_t (*get_request_time)(TSRMLS_D); /* Request Time */ void (*terminate_process)(TSRMLS_D); /* Child Terminate */ ? char *php_ini_path_override; // 覆蓋的ini路徑 ? ... ... }; 其中一些函數指針的說明如下: - startup 當SAPI初始化時,首先會調用該函數。如果服務器處理多個請求時,該函數只會調用一次。比如Apache的SAPI,它是以mod_php5的Apache模塊的形式加載到Apache中的,在這個SAPI中,startup函數只在父進程中創建一次,在其fork的子進程中不會調用。 - activate 此函數會在每個請求開始時調用,它會再次初始化每個請求前的數據結構。 - deactivate 此函數會在每個請求結束時調用,它用來確保所有的數據都,以及釋放在activate中初始化的數據結構。 - shutdown 關閉函數,它用來釋放所有的SAPI的數據結構、內存等。 - ub_write 不緩存的寫操作(unbuffered write),它是用來將PHP的數據輸出給客戶端,如在CLI模式下,其最終是調用fwrite實現向標準輸出輸出內容;在Apache模塊中,它最終是調用Apache提供的方法rwrite。 - sapi_error 報告錯誤用,大多數的SAPI都是使用的PHP的默認實現php_error。 - flush 刷新輸出,在CLI模式下通過使用C語言的庫函數fflush實現,在php_mode5模式下,使用Apache的提供的函數函數rflush實現。 - read_cookie 在SAPI激活時,程序會調用此函數,并且將此函數獲取的值賦值給SG(request_info).cookie_data。在CLI模式下,此函數會返回NULL。 - read_post 此函數和read_cookie一樣也是在SAPI激活時調用,它與請求的方法相關,當請求的方法是POST時,程序會操作$_POST、$HTTP_RAW_POST_DATA等變量。 - send_header 發送頭部信息,此方法一般的SAPI都會定制,其所不同的是,有些的會調服務器自帶的(如Apache),有些的需要你自己實現(如 FastCGI)。 以上的這些結構在各服務器的接口實現中都有定義。如Apache2的定義: static sapi_module_struct apache2_sapi_module = { "apache2handler", "Apache 2.0 Handler", ? php_apache2_startup, /* startup */ php_module_shutdown_wrapper, /* shutdown */ ? ... } 在PHP的源碼中實現了很多的實現,比如IIS的實現以及一些非主流的Web服務器實現,其文件結構如圖2.5所示: ![圖2.5 SAPI文件結構圖](http://box.kancloud.cn/2015-07-06_559a632a6a315.png) 圖2.5 SAPI文件結構圖 > 目前PHP內置的很多SAPI實現都已不再維護或者變的有些非主流了,PHP社區目前正在考慮將一些SAPI移出代碼庫。 社區對很多功能的考慮是除非真的非常必要,或者某些功能已近非常通用了,否則就在PECL庫中, 例如非常流行的APC緩存擴展將進入核心代碼庫中。 整個SAPI類似于一個面向對象中的模板方法模式的應用。SAPI.c和SAPI.h文件所包含的一些函數就是模板方法模式中的抽象模板,各個服務器對于sapi_module的定義及相關實現則是一個個具體的模板。 這樣的結構在PHP的源碼中有多處使用,比如在PHP擴展開發中,每個擴展都需要定義一個zend_module_entry結構體。這個結構體的作用與sapi_module_struct結構體類似,都是一個類似模板方法模式的應用。在PHP的生命周期中如果需要調用某個擴展,其調用的方法都是zend_module_entry結構體中指定的方法,如在上一小節中提到的在執行各個擴展的請求初始化時,都是統一調用request_startup_func方法,而在每個擴展的定義時,都通過宏PHP_RINIT指定request_startup_func對應的函數。以VLD擴展為例:其請求初始化為PHP_RINIT(vld),與之對應在擴展中需要有這個函數的實現: PHP_RINIT_FUNCTION(vld) { } 所以, 我們在寫擴展時也需要實現擴展的這些接口,同樣,當實現各服務器接口時也需要實現其對應的SAPI。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看