Lighttpd 插件系统（三）---PLUGIN_TO_SLOT宏

原文地址：http://www.cnblogs.com/kernel_hcy/archive/2010/03/14/1685777.html

 

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

        前面讲了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宏的内容：

#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也就不会知道使用哪个插件进行处理。因此，这样做也是没办法的事情。虽然这样会影响服务器的效率，毕竟每次都调用了很多无用的函数，但却有助于服务器的扩展。效率换扩展性，关键要把握一个度。