前面讲了lighttpd插件系统的加载和初始化,这一篇中,将介绍一下plugin.c中的宏PLUGIN_TO_SLOT。
在将PLUGIN_TO_SLOT宏之前,我们先来看看lighttpd中插件系统的对外接口。这个接口所对的“外”指的是lighttpd服务器。前面已经提到,在运行的过程中,lighttpd不知道所加载的插件都是干什么用的,只知道这些插件所实现的接口,也就是在plugin结构体中那些函数指针有哪些对于某个插件是NULL,哪些是具体的函数地址。
既然lighttpd只知道这些,那么它又是怎样调用这些插件的呢?
答案就在plugin.h文件中的下面一系列函数声明:
handler_t plugins_call_handle_uri_raw(server * srv, connection * con); handler_t plugins_call_handle_uri_clean(server * srv,connection * con); handler_t plugins_call_handle_subrequest_start(server * srv,connection * con); handler_t plugins_call_handle_subrequest(server * srv,connection * con); handler_t plugins_call_handle_request_done(server * srv,connection * con); handler_t plugins_call_handle_docroot(server * srv,connection * con); handler_t plugins_call_handle_physical(server * srv,connection * con); handler_t plugins_call_handle_connection_close(server * srv,connection * con); handler_t plugins_call_handle_joblist(server * srv,connection * con); handler_t plugins_call_connection_reset(server * srv,connection * con); handler_t plugins_call_handle_trigger(server * srv); handler_t plugins_call_handle_sighup(server * srv); handler_t plugins_call_init(server * srv); handler_t plugins_call_set_defaults(server * srv); handler_t plugins_call_cleanup(server * srv);
这些函数就是插件系统对外的接口。在运行过程中,lighttpd靠调用上面的这些函数调用插件。比如:在server.c的main函数中,就调用了plugins_call_set_defaults函数:
if (HANDLER_GO_ON != plugins_call_set_defaults(srv)) { log_error_write(srv, __FILE__, __LINE__, "s", "Configuration of plugins failed. Going down."); plugins_free(srv); network_close(srv); server_free(srv); return -1; }
如果你使用ctags+vim看代码,当在这些函数的调用处想跳转到定义时发现ctags没有找到这些函数的定义。难道这些函数没有实现?这显然是不会的。其实,这正是由于本文的重点───PLUGIN_TO_SLOT宏造成的。
打开plugin.c文件,会发现这几行代码:
PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_URI_CLEAN, handle_uri_clean)
PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_URI_RAW, handle_uri_raw)
PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_REQUEST_DONE,handle_request_done)
PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_CONNECTION_CLOSE,handle_connection_close)
PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_SUBREQUEST, handle_subrequest)
PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_SUBREQUEST_START,handle_subrequest_start)
PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_JOBLIST, handle_joblist)
PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_DOCROOT, handle_docroot)
PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_PHYSICAL, handle_physical)
PLUGIN_TO_SLOT(PLUGIN_FUNC_CONNECTION_RESET, connection_reset)
PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_TRIGGER, handle_trigger)
PLUGIN_TO_SLOT(PLUGIN_FUNC_HANDLE_SIGHUP, handle_sighup)
PLUGIN_TO_SLOT(PLUGIN_FUNC_CLEANUP, cleanup)
PLUGIN_TO_SLOT(PLUGIN_FUNC_SET_DEFAULTS, set_defaults)
再看看PLUGIN_SLOT宏的前两行:
#define PLUGIN_TO_SLOT(x, y) handler_t plugins_call_##y(server *srv, connection *con) {
这下明白了吧。上面那些函数是由这些宏调用模板化生成的。由于这些函数的代码具有很高的相似度(仅仅是调用的插件函数不同),通过宏模板进行生成,可以节约大量的代码,同时又不容易出错。这类似于C++中的模板。注:C语言预处理器运算符##为宏扩展提供了一种连接实际参数的手段。如果替换文本中的参数与##相邻,则改参数将被实际参数替换,##与前后的空白符将被删除,并对替换后的结果重新扫描。(摘自:C语言程序设计 K&R)在这里,plugins_call_和实参y拼接成函数名。
下面我们着重分析一下PLUGIN_SLOT宏的内容:
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
#define PLUGIN_TO_SLOT(x, y) handler_t plugins_call_##y(server *srv, connection *con) { plugin **slot; size_t j; if (!srv->plugin_slots) return HANDLER_GO_ON; slot = ((plugin ***)(srv->plugin_slots))[x]; if (!slot) return HANDLER_GO_ON; for (j = 0; j < srv->plugins.used && slot[j]; j++) { plugin *p = slot[j]; handler_t r; switch(r = p->y(srv, con, p->data)) { case HANDLER_GO_ON: break; case HANDLER_FINISHED: case HANDLER_COMEBACK: case HANDLER_WAIT_FOR_EVENT: case HANDLER_WAIT_FOR_FD: case HANDLER_ERROR: return r; default: log_error_write(srv, __FILE__, __LINE__, "sbs", #x, p->name, "unknown state"); return HANDLER_ERROR; } } return HANDLER_GO_ON; }
根据后面的宏调用可以看出,参数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
本文章由http://www.wifidog.pro/2015/04/17/wifidog%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90lighttpd%E6%8F%92%E4%BB%B6%E5%AE%8F%E5%AE%9A%E4%B9%89.html 整理编辑,转载请注明出处