您的位置:首页 > 编程语言 > PHP开发

PHP内核探索:再次探讨SAPI

2014-04-30 10:48 781 查看
在PHP的生命周期的各个阶段,一些与服务相关的操作都是通过SAPI接口实现。这些内置实现的物理位置在PHP源码的SAPI目录。这个目录存放了PHP对各个服务器抽象层的代码,例如命令行程序的实现,Apache的mod_php模块实现以及fastcgi的实现等等。

在各个服务器抽象层之间遵守着相同的约定,这里我们称之为SAPI接口。每个SAPI实现都是一个_sapi_module_struct结构体变量。(SAPI接口)。在PHP的源码中,当需要调用服务器相关信息时,全部通过SAPI接口中对应方法调用实现,而这对应的方法在各个服务器抽象层实现时都会有各自的实现。

下面是为SAPI的简单示意图:



以cgi模式和apache2服务器为例,它们的启动方法如下:

1
cgi_sapi_module.startup(&cgi_sapi_module)
//
cgi模式cgi/cgi_main.c文件
2
3
apache2_sapi_module.startup(&apache2_sapi_module);
4
//
apache2服务器apache2handler/sapi_apache2.c文件
这里的cgi_sapi_module是sapi_module_struct结构体的静态变量。它的startup方法指向php_cgi_startup函数指针。在这个结构体中除了startup函数指针,还有许多其它方法或字段。其部分定义如下:

01
struct
_sapi_module_struct
{
02
char
*name;
//
名字(标识用)
03
char
*pretty_name;
//
更好理解的名字(自己翻译的)
04
05
int
(*startup)(
struct
_sapi_module_struct
*sapi_module);
//
启动函数
06
int
(*shutdown)(
struct
_sapi_module_struct
*sapi_module);
//
关闭方法
07
08
int
(*activate)(TSRMLS_D);
//
激活
09
int
(*deactivate)(TSRMLS_D);
//
停用
10
11
int
(*ub_write)(
const
char
*str,
unsigned
int
str_length
TSRMLS_DC);
12
//
不缓存的写操作(unbufferedwrite)
13
void
(*flush)(
void
*server_context);
//
flush
14
struct
stat
*(*get_stat)(TSRMLS_D);
//
getuid
15
char
*(*
getenv
)(
char
*name,
size_t
name_len
TSRMLS_DC);
//
getenv
16
17
void
(*sapi_error)(
int
type,
const
char
*error_msg,
...);
/*
errorhandler*/
18
19
int
(*header_handler)(sapi_header_struct
*sapi_header,sapi_header_op_enumop,
20
sapi_headers_struct
*sapi_headersTSRMLS_DC);
/*
headerhandler*/
21
22
/*
sendheadershandler*/
23
int
(*send_headers)(sapi_headers_struct
*sapi_headersTSRMLS_DC);
24
25
void
(*send_header)(sapi_header_struct
*sapi_header,
26
void
*server_context
TSRMLS_DC);
/*
sendheaderhandler*/
27
28
int
(*read_post)(
char
*buffer,
uintcount_bytesTSRMLS_DC);
/*
readPOSTdata*/
29
char
*(*read_cookies)(TSRMLS_D);
/*
readCookies*/
30
31
/*
registerservervariables*/
32
void
(*register_server_variables)(zval
*track_vars_arrayTSRMLS_DC);
33
34
void
(*log_message)(
char
*message);
/*
Logmessage*/
35
time_t
(*get_request_time)(TSRMLS_D);
/*
RequestTime*/
36
void
(*terminate_process)(TSRMLS_D);
/*
ChildTerminate*/
37
38
char
*php_ini_path_override;
//
覆盖的ini路径
39
40
...
41
...
42
};
以上的这些结构在各服务器的接口实现中都有定义。如Apache2的定义:

1
static
sapi_module_struct
apache2_sapi_module={
2
"apache2handler"
,
3
"Apache
2.0Handler"
,
4
5
php_apache2_startup,
/*
startup*/
6
php_module_shutdown_wrapper,
/*
shutdown*/
7
8
...
9
}
目前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),与之对应在扩展中需要有这个函数的实现:

1
PHP_RINIT_FUNCTION(vld)
{
2
}
所以,我们在写扩展时也需要实现扩展的这些接口,同样,当实现各服务器接口时也需要实现其对应的SAPI。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: