引言

我看一个项目的时候,比较喜欢首先看它的架构和设计。因为这样在研读源码的时候,有一个指导作用,不会迷失于具体细节,并能够引导我如何去将点串成线,将线串成面。而且一个软件怎么样,很大程度上取决于它采用的架构。

本文主要介绍Mongoose的工作模型,及根据这个模型将代码大致串起来,找出主线。内容框架如下:

  1. I、线程模型
  2. II、从程序入口着手
  3. III、Mongoose的生命旅程

1、线程模型

Mongoose采用了一个自适应的线程池的模型。有一个主线程(master thread)用于打开配置端口和等待连接的到了。一旦新的连接到来,主线程将衍生一个新的线程去服务该连接。当衍生的线程处理完连接的请求之后,它会保持一段时间的空闲(可以通过配置选项-idle_time <seconds>控制空闲时间),在此期间主线程可能会传递另一个连接给它,让它服务。

因此,每个连接都是在自己的线程中执行,且线程数量随着web服务器的负载而变化。然而,最大的活跃线程数由-max_thread <number>控制。如果一旦总的线程数达到了这个阈值,当新的连接到来时,主线程将等到有线程空闲时在分配线程服务新到来的连接。以此同时,建立了TCP监听队列,即当没有线程空闲时到来的新连接会被置入该队列,当有线程空闲了会从队列中取出连接并服务。如果没有线程变空闲,而TCP队列又满了,web服务器将拒绝新到来的连接请求。

上面所述的过程大致如下所示:

Mongoose源码剖析:mongoose的工作模型

图1、线程模型

2、从程序入口着手

在《Mongoose源码剖析:Introduction and Installation》中,我们简单分析了Makefile文件知道生成的mongoose执行文件的入口肯定在main.c中(如果将Mongoose嵌入到你的应用程序中,就由你来决定入口了!)。在典型的main函数入口中,我们可以看到下面的流程:

main(){
启动mongoose及设置相关参数(或使用默认的);
声明几个信号的处理函数:
#ifndef _WIN32
    (void) signal(SIGCHLD, signal_handler);
#endif /* _WIN32 */
    (void) signal(SIGTERM, signal_handler);
    (void) signal(SIGINT, signal_handler);
ctx=mg_start();
process_command_line_arguments(ctx, argv);
进入死循环直到检测到程序结束标记while(exit_flag==0);
mg_stop();
}

上面即是main函数中的主流程。需要注意的是调用mg_start()之后返回一个mg_context结构体的实例,这个实例将会在整个连接请求中用到,而且如果你在启动mongoose中设置了参数选项,在下面的process_command_line_arguments()函数中还会对ctx进行修改。从这里我们也知道了,mongoose程序的核心入口时mg_start(),最后终结于mg_stop()。

3、Mongoose的生命旅程

通过上面的分析我们知道Mongoose起始于mg_stop(),终结于mg_stop()。下面我们就从生命之初到生命终结之间的“故事”。说明:在这里我们不会去过于追究细节,只是串线式的把Mongoose的生命流程串起来,哪些细节或许后续的文章来解释,或者留给读者你去做了!

在mg_start()主要是做一些初始化的工作,最后才会正式进入工作服务于client。这里的初始化工作就好比一个人的出生需要十月怀胎,为诞生积蓄能量,要从受精卵长成一个完整的人。在准备工作完成之后,mg_start()会启动一个主线程master_thread,它用于监听所有的client连接请求。

启动一个主线程即启动了一个web server,在主线程中首先会将该server监听的地址(socket)加入到监听集合中去。然后一直监听该端口,只要有client的连接请求到来,它会调用accept_new_connection()去处理连接请求。

接下来,我们关注的是accept_new_connection()是如何去处理连接请求的。首先它会进行一些预判工作,决定是否允许该连接。如果允许,则调用put_socket()并将处理工作转交给它,所谓权力下放。

在put_socket()首先也会进行一些预判工作——判断mg_context结构体的成员变量queue队列是否已满,如果满了就等待直到queue有位置容纳请求。还有一点要说明的是:由于有可能多个client请求同时到达,对queue进行操作,所以在put_socket()中一开始就设置(void) pthread_mutex_lock(&ctx->thr_mutex);而且请求是通过调节变量来控制等待queue是否有位置容纳请求(void) pthread_cond_wait(&ctx->full_cond, &ctx->thr_mutex)。说了这么多准备工作,现在该正式进入工作了。至此,如果没有空闲进程且进程数量没有达到最大阈值,就会启动一个新的工作进程worker_thread去处理client的请求。之后就是释放信号量等资源,让其它client请求也能够请求到资源工作,如启动了一个工作进程去处理client请求,这时queue就空出一个位置了,它会调用pthread_cond_signal(&ctx->empty_cond)让等待的client请求知道queue中有位置了。最后就是释放put_socket()中一开始设置的锁,(void) pthread_mutex_unlock(&ctx->thr_mutex)。

到了这里,client的请求已经被分配打一个工作线程中去了。而且不同的client请求处理运行在不同的工作线程中,能够互不干扰。在worker_thread中,首先与client建立连接,只有连接上了才能为client服务。连接建立之后调用process_new_connection()去处理请求。处理完之后返回关闭连接,并通过信号机制告诉主线程,我的做工做完了。

在process_new_connection()中处理工作:首先解析请求parse_http_request(),知道请求的内容;接着就是进入Mongoose处理client请求的真正核心工作了analyze_request()。这里就不详细介绍parse_http_request()、analyze_request()是如何去解析、验证、提供具体服务的,否则就陷入了细节出不来了,这里主要是介绍Mongoose的生命之旅的主线。

下面用图形来形象描述一下Mongoose的生命之旅,说明:该图形并不是一个精确的逻辑关系,图中的箭头方向只是描述了程序的大概流程,并都是上级调用下级的关系,如并不是parse_http_request()调用analyze_request()等,而实际上它们都是在process_new_connection()被调用。

Mongoose源码剖析:mongoose的工作模型

图2、Mongoose的大概生命主线

4、总结

至此,算是介绍完了Mongoose的一个完整的工作模型了,你可以安装此主线去进行code review。只有你脑海里有这样一个模型,你就不会在研读代码是迷失了。

当然Mongoose提供的很多api,这里都没有介绍到,因为它不是本文的重点。我希望此能够带后来者步入Mongoose源码研读的大门,给后来者节省徘徊在门外停滞不前的时间。