1.linux0.11源码分析-fork进程
2.sourcecode深入理解从LinuxC源代码中一路读下去readlinuxc
3.UMI3源码解析系列之构建原理
4.nginx源码分析--master和worker进程模型
linux0.11源码分析-fork进程
在操作系统中,码解Linux0.源码中的码解fork函数执行流程分为启动和系统调用两个阶段。启动阶段首先在init/main.c中执行init用于启动shell,码解让用户执行命令。码解
在include/unistd.h中定义了宏,码解表示将__NR_fork的码解表格app源码值复制给eax寄存器,并将_res与eax绑定。码解使用int 0x中断后,码解系统调用函数system_call被调用,码解从sys_call_table中找到对应的码解函数执行。fork函数执行时,码解操作系统会在内核栈里保存相关寄存器,码解准备中断返回。码解
接着,码解操作系统通过int调用system_call,码解在kernel/system_call.s中执行call _sys_call_table(,%eax,4)指令。内核栈中,因为是uzer.me源码段内跳转,所以cs不需要入栈。ip指向call指令的下一句代码。执行call指令进入系统调用表。
在includ/linux/sys.h中,系统调用表是一个数组,根据eax即系统函数编号找到对应的函数执行。对于fork,__NR_fork值2被放入eax寄存器,%eax * 4找到sys_fork。执行sys_fork后,调用find_empty_process函数找到可用的进程号,并放入eax寄存器返回。
接着,系统调用执行copy_process函数建立新进程结构体并复制数据。新进程的ip出栈,执行完copy_process后,系统调用返回,机构预测指标源码内核栈状态改变。此阶段最后通过iret指令弹出寄存器,恢复中断前状态。
总结,fork函数通过复制当前进程结构体、处理信号并初始化新进程,实现父进程与子进程的创建与共享。子进程返回值为0,父进程返回新子进程的pid。通过fork函数的执行,操作系统能够高效地创建进程,实现多任务处理。
sourcecode深入理解从LinuxC源代码中一路读下去readlinuxc
Source Code(源代码)深入理解:从Linux C源代码中一路读下去
Linux( 差异化系统)是一个开放的操作系统,由内核及由各种软件组成。Linux C源代码提供了一种深入理解Linux系统的方式,但首先我们需要对C语言有一定的了解。
Linux C源代码包括所有的简单的闹钟源码Linux内核功能模块的代码,以及大量的应用层的软件,比如用户、处理器、内存管理等。每个模块都由一系列的C语言函数组成,例如:fork()、pause()、connect()等。当读取源代码时,需要理解这些函数的功能,以及它们之间的关系,这样才能深入理解每个模块是如何运作的。
要深入理解Linux C源代码,它首先解释函数如何实现其功能,分析它们之间的依赖关系,这样就可以确定调用这些函数的一般设计算法,从而实现更有效的家庭相册html源码程序。
当读取源代码时,要紧跟这些函数的实现方式,这会帮助我们更好地理解每个模块的设计思想,并获得更深入地了解运行Linux系统的细节,例如CPU分配,内存分配,调度算法,文件系统,进程管理等等。其次,需深入了解C语言的变量类型,指针和引用的用法。
要广泛深入地理解Linux C源代码,我们需要熟练地使用Linux,有一定的编码经验,使用gcc等Linux编译器,以及设计调试工具,如GDB(GNU调试器)等。
因此,从Linux C源代码中,深入理解可以帮助我们更好地理解Linux内核,以及它运行的社区软件,有助于用更容易的方式开发更有效率的程序给Linux系统。
UMI3源码解析系列之构建原理
基于前面umi插件机制的原理可以了解到,umi是一个插件化的企业级前端框架,它配备了完善的插件体系,这也使得umi具有很好的可扩展性。umi的全部功能都是由插件完成的,构建功能同样是以插件的形式完成的。下面将从以下两个方面来了解umi的构建原理。UMI命令注册想了解umi命令的注册流程,咱们就从umi生成的项目入手。
从umi初始化的项目package.json文件看,umi执行dev命令,实际执行的是start:dev,而start:dev最终执行的是umidev。
"scripts":{ "dev":"npmrunstart:dev","start:dev":"cross-envREACT_APP_ENV=devMOCK=noneUMI_ENV=devumidev"}根据这里的umi命令,我们找到node_modules里的umi文件夹,看下umi文件夹下的package.json文件:
"name":"umi","bin":{ "umi":"bin/umi.js"}可以看到,这里就是定义umi命令的地方,而umi命令执行的脚本就在bin/umi.js里。接下来咱们看看bin/umi.js都做了什么。
#!/usr/bin/envnoderequire('v8-compile-cache');constresolveCwd=require('@umijs/deps/compiled/resolve-cwd');const{ name,bin}=require('../package.json');constlocalCLI=resolveCwd.silent(`${ name}/${ bin['umi']}`);if(!process.env.USE_GLOBAL_UMI&&localCLI&&localCLI!==__filename){ constdebug=require('@umijs/utils').createDebug('umi:cli');debug('Usinglocalinstallofumi');require(localCLI);}else{ require('../lib/cli');}判断当前是否执行的是本地脚手架,若是,则引入本地脚手架文件,否则引入lib/cli。在这里,我们未开启本地脚手架指令,所以是引用的lib/cli。
//获取进程的版本号constv=process.version;//通过yParser工具对命令行参数进行处理,此处是将version和help进行了简写constargs=yParser(process.argv.slice(2),{ alias:{ version:['v'],help:['h'],},boolean:['version'],});//若参数中有version值,并且args._[0]为空,此时将version字段赋值给args._[0]if(args.version&&!args._[0]){ args._[0]='version';constlocal=existsSync(join(__dirname,'../.local'))?chalk.cyan('@local'):'';console.log(`umi@${ require('../package.json').version}${ local}`);//若参数中无version值,并且args._[0]为空,此时将help字段复制给args._[0]}elseif(!args._[0]){ args._[0]='help';}处理完version和help后,紧接着会执行一段自执行代码:
(async()=>{ try{ //读取args._中第一个参数值switch(args._[0]){ case'dev'://若当前运行环境是dev,则调用Node.js的核心模块child_process的fork方法衍生一个新的Node.js进程。scriptPath表示要在子进程中运行的模块,这里引用的是forkedDev.ts文件。constchild=fork({ scriptPath:require.resolve('./forkedDev'),});//ref:///api/process/signal_events.html///post/nginx源码分析--master和worker进程模型
一、Nginx整体架构
正常执行中的nginx会有多个进程,其中最基本的是master process(主进程)和worker process(工作进程),还可能包括cache相关进程。
二、核心进程模型
启动nginx的主进程将充当监控进程,主进程通过fork()产生的子进程则充当工作进程。
Nginx也支持单进程模型,此时主进程即是工作进程,不包含监控进程。
核心进程模型框图如下:
master进程
监控进程作为整个进程组与用户的交互接口,负责监护进程,不处理网络事件,不负责业务执行,仅通过管理worker进程实现重启服务、平滑升级、更换日志文件、配置文件实时生效等功能。
master进程通过sigsuspend()函数调用大部分时间处于挂起状态,直到接收到信号。
master进程通过检查7个标志位来决定ngx_master_process_cycle方法的运行:
sig_atomic_t ngx_reap;
sig_atomic_t ngx_terminate;
sig_atomic_t ngx_quit;
sig_atomic_t ngx_reconfigure;
sig_atomic_t ngx_reopen;
sig_atomic_t ngx_change_binary;
sig_atomic_t ngx_noaccept;
进程中接收到的信号对Nginx框架的意义:
还有一个标志位:ngx_restart,仅在master工作流程中作为标志位使用,与信号无关。
核心代码(ngx_process_cycle.c):
ngx_start_worker_processes函数:
worker进程
worker进程主要负责具体任务逻辑,主要关注与客户端或后端真实服务器之间的数据可读/可写等I/O交互事件,因此工作进程的阻塞点在select()、epoll_wait()等I/O多路复用函数调用处,等待数据可读/写事件。也可能被新收到的进程信号中断。
master进程如何通知worker进程进行某些工作?采用的是信号。
当收到信号时,信号处理函数ngx_signal_handler()会执行。
对于worker进程的工作方法ngx_worker_process_cycle,它主要关注4个全局标志位:
sig_atomic_t ngx_terminate;//强制关闭进程
sig_atomic_t ngx_quit;//优雅地关闭进程(有唯一一段代码会设置它,就是接受到QUIT信号。ngx_quit只有在首次设置为1时,才会将ngx_exiting置为1)
ngx_uint_t ngx_exiting;//退出进程标志位
sig_atomic_t ngx_reopen;//重新打开所有文件
其中ngx_terminate、ngx_quit、ngx_reopen都将由ngx_signal_handler根据接收到的信号来设置。ngx_exiting标志位仅由ngx_worker_cycle方法在退出时作为标志位使用。
核心代码(ngx_process_cycle.c):