nginx_4_1

Posted ~千里之行,始于足下~

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了nginx_4_1相关的知识,希望对你有一定的参考价值。

  • 一:信号高级认识范例
    //ps -eo pid,ppid,sid,tty,pgrp,comm,stat,cmd | grep -E ‘bash|PID|nginx

    • 用kill 发送 USR1信号给进程
    • (1)执行信号处理函数被卡住了10秒,这个时候因为流程回不到main(),所以main中的语句无法得到执行;
    • (2)在触发SIGUSR1信号并因此sleep了10秒种期间,就算你多次触发SIGUSR1信号,也不会重新执行SIGUSR1信号对应的信号处理函数,而是会等待上一个SIGUSR1信号处理函数执行完毕才 第二次执行SIGUSR1信号处理函数;
      • 换句话说:在信号处理函数被调用时,操作系统建立的新信号屏蔽字(sigprocmask()),自动包括了正在被递送的信号,因此,保证了在处理一个给定信号的时候,如果这个信号再次发生,那么它会阻塞到对前一个信号处理结束为止;
    • (3)不管你发送了多少次kill -usr1信号,在该信号处理函数执行期间,后续所有的SIGUSR1信号统统被归结为一次。
      比如当前正在执行SIGUSR1信号的处理程序但没有执行完毕,这个时候,你又发送来了5次SIGUSR1信号,那么当SIGUSR1信号处理程序,执行完毕(解除阻塞),SIGUSR1信号的处理程序也只会被调用一次(而不会分别调用5次SIGUSR1信号的处理程序)。

    //kill -usr1,kill -usr2

    • (1)执行usr1信号处理程序,但是没执行完时,是可以继续进入到usr2信号处理程序里边去执行的,这个时候,相当于usr2信号处理程序没执行完毕,usr1信号处理程序也没执行完毕;此时再发送usr1和usr2都不会有任何响应;
    • (2)既然是在执行usr1信号处理程序执行的时候来了usr2信号,导致又去执行了usr2信号处理程序,这就意味着,只有usr2信号处理程序执行完毕,才会返回到usr1信号处理程序,只有usr1信号处理程序执行完毕了,才会最终返回到main函数主流程中去继续执行;

思考:如果我希望在我处理SIGUSR1信号,执行usr1信号处理程序的时候,如果来了SIGUSR2信号,我想堵住(屏蔽住),
  不想让程序流程跳到SIGUSR2信号处理中去执行,可以做到的;我们后续会讲解其他的如何屏蔽信号的方法;


#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <errno.h>


//信号处理函数
void sig_usr(int signo)
         
    if(signo == SIGUSR1)
    
        printf("收到了SIGUSR1信号,我休息10秒......!\\n");
        sleep(10);
        printf("收到了SIGUSR1信号,我休息10秒完毕,苏醒了......!\\n");
    
    else if(signo == SIGUSR2)
    
        printf("收到了SIGUSR2信号,我休息10秒......!\\n");
        sleep(10);
        printf("收到了SIGUSR2信号,我休息10秒完毕,苏醒了......!\\n");
    
    else
    
        printf("收到了未捕捉的信号%d!\\n",signo);
    


int main(int argc, char *const *argv)

    if(signal(SIGUSR1,sig_usr) == SIG_ERR)  //系统函数,参数1:是个信号,参数2:是个函数指针,代表一个针对该信号的捕捉处理函数
    
        printf("无法捕捉SIGUSR1信号!\\n");
    
    if(signal(SIGUSR2,sig_usr) == SIG_ERR) 
    
        printf("无法捕捉SIGUSR2信号!\\n");
    
    
    for(;;)
    
        sleep(1); //休息1秒    
        printf("休息1秒~~~~!\\n");
    
    printf("再见!\\n");
    return 0;




二:服务器架构初步
//(2.1)目录结构规划(make编译)
//特别注意:不固安是目录还是文件,文件名中一律不要带空格,一律不要用中文,最好的方式:字母,数字,下划线;

  • 主目录名nginx
    • a)_include目录:专门存放各种头文件; 如果分散:#include “sfaf/sdafas/safd.h”

    • b)app目录:放主应用程序.c(main()函数所在的文件)以及一些比较核心的文件;

      • b.1)link_obj:临时目录:会存放临时的.o文件,这个目录不手工创建,后续用makefile脚本来创建
      • b.2)dep:临时目录,会存放临时的.d开头的依赖文件,依赖文件能够告知系统哪些相关的文件发生变化,需要重新编译,后续用makefile脚本来创建
      • b.3)nginx.c:主文件,main()入口函数就放到这里;
      • b.4)ngx_conf.c ,普通的源码文件,跟主文件关系密切,又不值得单独放在 一个目录;
    • c)misc目录:专门存放各种杂合性的不好归类的1到多个.c文件;暂时为空

    • d)net目录:专门存放和网络处理相关的1到多个.c文件,暂时为空

    • e)proc目录:专门存放和进程处理有关的1到多个.c文件,暂时为空

    • f)signal目录:专门用于存放和信号处理 有关的1到多个.c文件;

      • ngx_signal.c
    • (2.2)编译工具make的使用概述(编译出可执行文件)

      • a)我们要借助make的命令来编译:能够编译,链接。。。。最终生成可执行文件,大型项目一般都用make来搞;
    • b)make命令的工作原理,就去当前目录读取一个叫做makefile的文件(文本文件),根据这个makefile文件里的

      • 规则把咱们的源代码编译成可执行文件;咱们开发者的任务就是要把这个makefile文件写出来;
      • 这个makefile里边就定义了我们怎么去编译整个项目的编译、链接规则
        //有类似autotools自动生成makefile,这里不讲
        //c)makefile文件:文本文件,utf8编码格式,没有扩展名,一般放在根目录下[也会根据需要放在子目录](这里nginx)
    • 规划一下makefile文件的编写

      • a)nginx根目录下我会放三个文件:
        • a.1)makefile:是咱们编译项目的入口脚本,编译项目从这里开始,起总体控制作用;
      • a.2)config.mk:这是个配置脚本,被makefile文件包含;单独分离出来是为了应付一些可变的东西,所以,一般变动的东西都往这里搞;
      • a.3)common.mk:是最重要最核心的编译脚本,定义makefile的编译规则,依赖规则等,通用性很强的一个脚本,
    • b)每个子目录下(app,signal)都有一个叫做makefile的文件,每个这个makefile文件,都会包含根目录下的common.mk,

    • c)其他规划,上边讲过;
      //app/link_obj临时目录,存放.o目标文件
      //app/dep:存放.d开头的依赖关系文件;

    • (2.3)makefile脚本用法介绍

      • a)编译项目,生成可执行文件
        • make
        • make clean
    • (2.4)makefile脚本具体实现讲解

      • 从common.mk讲起
      • 将来增加新目录时:
      • a)修改根目录下的config.mk来增加该目录
      • b)在对应的目录下放入makefile文件,内容参考signal目录ixa的makefile文件即可

以上是关于nginx_4_1的主要内容,如果未能解决你的问题,请参考以下文章

nginx_4_1

nginx__的简单搭建和 wsgi

nginx_3_4

nginx_3_4

nginx_3_4

03_Nginx加入新模块