Lighttpd1.4.20源码分析之插件系统(3)---PLUGIN_TO_SLOT宏

前面讲了lighttpd插件系统的加载和初始化,这一篇中,将介绍一下plugin.c中的宏PLUGIN_TO_SLOT。
在将PLUGIN_TO_SLOT宏之前,我们先来看看lighttpd中插件系统的对外接口。这个接口所对的“外”指的是lighttpd服务器。前面已经提到,在运行的过程中,lighttpd不知道所加载的插件都是干什么用的,只知道这些插件所实现的接口,也就是在plugin结构体中那些函数指针有哪些对于某个插件是NULL,哪些是具体的函数地址。
既然lighttpd只知道这些,那么它又是怎样调用这些插件的呢?
答案就在plugin.h文件中的下面一系列函数声明:

1 handler_t plugins_call_handle_uri_raw(server * srv, connection * con);
2 handler_t plugins_call_handle_uri_clean(server * srv,connection * con);
3 handler_t plugins_call_handle_subrequest_start(server * srv,connection * con);
4 handler_t plugins_call_handle_subrequest(server * srv,connection * con);
5 handler_t plugins_call_handle_request_done(server * srv,connection * con);
6 handler_t plugins_call_handle_docroot(server * srv,connection * con);
7 handler_t plugins_call_handle_physical(server * srv,connection * con);
8 handler_t plugins_call_handle_connection_close(server * srv,connection * con);
9 handler_t plugins_call_handle_joblist(server * srv,connection * con);
10 handler_t plugins_call_connection_reset(server * srv,connection * con);
11 handler_t plugins_call_handle_trigger(server * srv);
12 handler_t plugins_call_handle_sighup(server * srv);
13 handler_t plugins_call_init(server * srv);
14 handler_t plugins_call_set_defaults(server * srv);
15 handler_t plugins_call_cleanup(server * srv);

 


这些函数就是插件系统对外的接口。在运行过程中,lighttpd靠调用上面的这些函数调用插件。比如:在server.c的main函数中,就调用了plugins_call_set_defaults函数:

1 if (HANDLER_GO_ON != plugins_call_set_defaults(srv))
2 {
3 log_error_write(srv, __FILE__, __LINE__, "s",
4 "Configuration of plugins failed. Going down.");
5 plugins_free(srv);
6 network_close(srv);
7 server_free(srv);
8 return -1;
9 }

 


如果你使用ctags+vim看代码,当在这些函数的调用处想跳转到定义时发现ctags没有找到这些函数的定义。难道这些函数没有实现?这显然是不会的。其实,这正是由于本文的重点───PLUGIN_TO_SLOT宏造成的。
打开plugin.c文件,会发现这几行代码:

1 PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_URI_CLEAN, handle_uri_clean)
2 PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_URI_RAW, handle_uri_raw)
3 PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_REQUEST_DONE,handle_request_done)
4 PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_CONNECTION_CLOSE,handle_connection_close)
5 PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_SUBREQUEST, handle_subrequest)
6 PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_SUBREQUEST_START,handle_subrequest_start)
7 PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_JOBLIST, handle_joblist)
8 PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_DOCROOT, handle_docroot)
9 PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_PHYSICAL, handle_physical)
10 PLUGIN_TO_SLOT(PLUGIN_FUNC_CONNECTION_RESET, connection_reset)
11 PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_TRIGGER, handle_trigger)
12 PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_SIGHUP, handle_sighup)
13 PLUGIN_TO_SLOT(PLUGIN_FUNC_CLEANUP, cleanup)
14 PLUGIN_TO_SLOT(PLUGIN_FUNC_SET_DEFAULTS, set_defaults)

 


再看看PLUGIN_SLOT宏的前两行:

1 #define PLUGIN_TO_SLOT(x, y) \
2 handler_t plugins_call_##y(server *srv, connection *con) {\

 


这下明白了吧。上面那些函数是由这些宏调用模板化生成的。由于这些函数的代码具有很高的相似度(仅仅是调用的插件函数不同),通过宏模板进行生成,可以节约大量的代码,同时又不容易出错。这类似于C++中的模板。注:C语言预处理器运算符##为宏扩展提供了一种连接实际参数的手段。如果替换文本中的参数与##相邻,则改参数将被实际参数替换,##与前后的空白符将被删除,并对替换后的结果重新扫描。(摘自:C语言程序设计 K&R)在这里,plugins_call_和实参y拼接成函数名。
下面我们着重分析一下PLUGIN_SLOT宏的内容:

1 #define PLUGIN_TO_SLOT(x, y) \
2 handler_t plugins_call_##y(server *srv, connection *con) {\
3 plugin **slot;\
4 size_t j;\
5 if (!srv->plugin_slots) return HANDLER_GO_ON;\
6 slot = ((plugin ***)(srv->plugin_slots))[x];\
7 if (!slot) return HANDLER_GO_ON;\
8 for (j = 0; j < srv->plugins.used && slot[j]; j++) { \
9 plugin *p = slot[j];\
10 handler_t r;\
11 switch(r = p->y(srv, con, p->data)) {\
12 case HANDLER_GO_ON:\
13 break;\
14 case HANDLER_FINISHED:\
15 case HANDLER_COMEBACK:\
16 case HANDLER_WAIT_FOR_EVENT:\
17 case HANDLER_WAIT_FOR_FD:\
18 case HANDLER_ERROR:\
19 return r;\
20 default:\
21 log_error_write(srv, __FILE__, __LINE__, "sbs", #x, p->name, "unknown state");\
22 return HANDLER_ERROR;\
23 }\
24 }\
25 return HANDLER_GO_ON;\
26 }

 


根据后面的宏调用可以看出,参数x是plugin_t枚举类型,y是plugin结构体中函数指针成名的名字。在宏调用中,x和y是相对应的。
PLUGIN_SLOT宏首先通过参数y拼接出函数名。如:这个宏调用
PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_URI_CLEAN, handle_uri_clean),拼接得到的函数名为plugins_call_handle_uri_clean,加上参数和返回值,正好是plugin.h中的函数handler_t plugins_call_handle_uri_clean(server * srv, connection * con)。其他的以此类推。
    这条语句slot = ((plugin ***)(srv->plugin_slots))[x];通过宏参数x得到plugin_slots的第x列。plugin_slots的结构在前面的文章中已经讲解过了。不熟悉的读者可以再回头看看。这列中包含所有具有参数x所对应的功能的插件的指针。也就是,plugin结构体的成员变量y不为NULL的所有plugin实例的指针。接着,在for循环中,调用这些插件的y函数,就是这句:switch(r = p->y(srv, con, p->data))。后面就是一些返回值和错误处理了。
    读者也许早就发现在plugin.c文件中有两个PLUGIN_SLOT宏。猛地一看没有任何差别。确实,着两个宏基本上都一样,只有一点不同:第二个宏的switch语句中调用y函数时,参数少了一个con:switch(r = p->y(srv, p->data))。这是他们唯一的差别。读者可以看看plugin结构体中的函数指针,有四个是两个参数的(server * srv, void *p_d),其他都是三个参数(server * srv, connection * con, void *p_d)。
    在这里有一个很有意思的问题。我们注意到,在所有plugins_call_XXX函数中,由于都是通过上面的PLUGIN_SLOT宏生成的。那么,这些函数在被lighttpd进行调用的时候,无论来的请求想要干什么,lighttpd都会逐一调用所有插件对应的函数。这就有一个问题了:如果所调用的第一个插件所具有的功能不是这个连接所想要的功能,这不就出错了么?但是反过来想想,既然要隐藏插件的所有细节,那么lighttpd也就无从知道哪些插件是干什么的。因此,对与一个连接,lighttpd也就不会知道使用哪个插件进行处理。因此,这样做也是没办法的事情。虽然这样会影响服务器的效率,毕竟每次都调用了很多无用的函数,但却有助于服务器的扩展。效率换扩展性,关键要把握一个度。
    那么lighttpd无法确定连接该用哪个插件来处理,那么插件自己就必须知道哪些连接是自己该处理的。这涉及到连接的细节处理,我们先暂且放一放。从下一篇开始,将讲解一下fd event系统,在分析具体的连接的处理时,在讲解这个问题。
    下一篇,介绍lighttpd中的fdevents结构体和fd eve

 

posted @ 2010-03-14 22:28  kernel@hcy  阅读(3523)  评论(0编辑  收藏