这一章看的比较混乱,可能是因为例子少;再有就是,这一章就是一个铺垫的章节。

9.2 terminal logins

  啥叫termnial? 我感觉书上的terminal指的更可能是一些物理设备(keyboard, modem这类的)

  /etc/ttys里面存着这些终端,一行代表一个终端的信息。

  限于基础知识有限,上面的内容可能理解的有误,但是对于terminal logins有一点是可以确定的:计算机事先知道有多少terminals可以logins。

  其中BSD Terminal Logins是重点讲述的,其主要流程如下流程如下:

    init (process ID 1)

    ⬇️ fork once per terminal;creates empty environment

    init

    ⬇️ each child execs getty

    getty

    ⬇️ opens terminal device; real user name; initial environment set;

    login

    ⬆️

    ⬇️  file descriptor 0 1 2

    terminal device driver

    ⬆️

    ⬇️  hard-wired connection

    user at a terminal

  在上面的过程中,可以看到Chapter 8 中fork exec的作用。

(1)先看到getty(包括getty)发生了什么

  environment:init给getty的还是一个empty environment;getty自己create了一个environment再传给login,这个时候environment中就已经包含了terminal的信息了(如TERM)。

  open terminal device: 打开terminal device,设定file descriptor 0 1 2 (input、output、error)

  read user name: output类似“login:”等着用户输入

  可以用下面的内容来理解getty:

  execle("/bin/login", "login", "-p", username, (char*)0, envp);

  最后getty调用了login program

(2)再看login做了哪些事情

  a. 获取密码,校验密码。

  b. 转换到这个用户的home路径

  c. 把terminal device的ownship转换给用户

  d. 设定groupid

  e. ...

9.3 Network Logins

  与terminal logins不同的是,计算机事先是不知道有多少,那些,谁,要network logins的。

  因此,没有像/etc/ttys一行的terminal配置文件可以读。怎么办呢?这就要用一种类似service的方式去处理。

  为了能够最终统一处理terminal和network的logins,unix系统中存在一种pseudo terminal的机智,可以翻译为虚拟终端。

  为什么要有虚拟终端呢?

  我觉得有两个原因:

  1)作为终端用户,个人习惯来说,远程网络操作和terminal操作不希望有啥不同

  2)作为unix系统,既然已经开发了terminal logins的程序,自然希望network logins的程序也能复用terminal logins的处理程序。因为二者除了登入的方式不同,一旦与系统发生交互,处理的内容都是类似的。

  因此,pseudo terminal就出现了,完成了上述的诉求。即使从network logins的,只要login完成了,与terminal的操作并无两样。

  下面只需要关注如何产生pseudo terminal的,流程如下。

                        init process ID 1

TCP connection request from TELNET client → ⬇️ executes the shell script /etc/rc

                        inetd

                        ⬇️ fork (when connection request arrives from TELNET client)

                        inetd

                        ⬇️

                        telnetd

                        ⬇️

                        pseudo terminal device

                        ⬇️ fork

                        parent process : handle the communication across the network connection

                        child process : does an exec of the login program

                        parent & child connected through the pseudo terminal

                        child process

                        ⬆️

                        ⬇️

                        login shell

  上述的过程就是:

    在系统的start-up阶段,init会执行一个/etc/rc的shell script,这个脚本的目的是启动inetd daemons。

    随后,inetd daemons就一直等着,直到有来自telnet client的请求就fork出去一个小弟inetd去处理这个请求。

    这个inetd小弟处理请求的方式是执行TELNET server,即telnetd。

    随后telnetd随即打开一个pseudo terminal device,并且用fork的方式一分为二:

      parent process : 负责管network connection的事情

      child process : 负责管执行login相关的东西

      parent 与 child 之间通过pseudo terminal来关联

9.4 Process Group

   一堆process组成一个process group,猜测有process group是为了方便集体对某种类型的process进行集体操作。不细说。

9.5 Sessions

   多个process groups构成了Session。

9.8 Job Control

  这一部分书上有个了例子,从结果来看:不带job control的shell,一个terminal只能产生一个PGID;带job control的shell,一个terminal可以产生好几个PGID.

9.10 Orphaned Process Groups

  由于缺乏后面signal的知识,就只看9.12这个代码。

  代码不复杂,这里不详细记录了。

  只说让我疑惑的地方。

...
signal(SIGHUP, sig_hup);
kill(getpid(), SIGTSTP);
...

  源代码中有这么两行,是在fork后的child process中执行的。

  先放着signal不管,这个kill就比较让人看着不好理解:都kill了,为什么child process后面的语句还能执行呢?

  先man 2 kill一下:“kill - send signal to a process”。这才知道,kill做的事情是发送一个信号

  那么再看一下发送的这个信号SIGTSTP是啥意思呢?

  书上有这么一段话:“Unfortunately, the term stop has different meanings.....Therefore, the terminal driver calls the character that generates the interactive stop signal the suspend character, not the stop character”。

  可以理解为:这里的stop并不是说直接给弄没了,而是先让这个进程等着的意思。

  再回来看signal。

  源代码中故意弄没了parent process,留着child process,这样就造成了orphaned process group的情况。按照系统的要求,对于orphaned process group中的所有的余留的进程,都会被发送一个hang-up的信号(SIGHUP),随后伴随着就SIGCONT的信号。signal这个语句就是为了能让child process接收到SIGHUP这个信号,并继续执行下去。

  通过这个事情,这个kill跟他原来的意思还是差挺多的,还是要多注意一些。

  

     

  

  

  

【APUE】Chapter9 Process Relationships的更多相关文章

  1. 【APUE】Chapter8 Process Control

    这章的内容比较多.按照小节序号来组织笔记的结构:再结合函数的示例带代码标注出来需要注意的地方. 下面的内容只是个人看书时思考内容的总结,并不能代替看书(毕竟APUE是一本大多数人公认的UNIX圣经). ...

  2. 【APUE】Chapter7 Process Environment

    这一章内容是Process的基础准备篇章.这一章的内容都是基于C Programm为例子. (一)进程开始: kernel → C start-up rountine → main function ...

  3. 【APUE】Chapter10 Signals

    Signal主要分两大部分: A. 什么是Signal,有哪些Signal,都是干什么使的. B. 列举了非常多不正确(不可靠)的处理Signal的方式,以及怎么样设计来避免这些错误出现. 10.2 ...

  4. 【C#】无损转换Image为Icon 【C#】组件发布:MessageTip,轻快型消息提示窗 【C#】给无窗口的进程发送消息 【手记】WebBrowser响应页面中的blank开新窗口及window.close关闭本窗体 【手记】调用Process.EnterDebugMode引发异常:并非所有引用的特权或组都分配给呼叫方 【C#】DataRowState演变备忘

    [C#]无损转换Image为Icon 如题,市面上常见的方法是: var handle = bmp.GetHicon(); //得到图标句柄 return Icon.FromHandle(handle ...

  5. 【APUE】Chapter16 Network IPC: Sockets & makefile写法学习

    16.1 Introduction Chapter15讲的是同一个machine之间不同进程的通信,这一章内容是不同machine之间通过network通信,切入点是socket. 16.2 Sock ...

  6. 【手记】调用Process.EnterDebugMode引发异常:并非所有引用的特权或组都分配给呼叫方

    刚上线一个新版本,其中有台电脑打开软件就报[xx的类型初始值设定项引发异常](还好不是一大波电脑,新东西上线就怕哀鸿遍野),如图: 显然是该类型的静态构造函数中抛异常了(红线处就是类名),遂打开该类, ...

  7. 【APUE】Chapter17 Advanced IPC & sign extension & 结构体内存对齐

    17.1 Introduction 这一章主要讲了UNIX Domain Sockets这样的进程间通讯方式,并列举了具体的几个例子. 17.2 UNIX Domain Sockets 这是一种特殊s ...

  8. 【APUE】Chapter15 Interprocess Communication

    15.1 Introduction 这部分太多概念我不了解.只看懂了最后一段,进程间通信(IPC)内容被组织成了三个部分: (1)classical IPC : pipes, FIFOs, messa ...

  9. 【APUE】Chapter14 Advanced I/O

    14.1 Introduction 这一章介绍的内容主要有nonblocking I/O, record locking, I/O multiplexing, asynchronous I/O, th ...

随机推荐

  1. yum 源搭建

    RHEL系统部署网络yum源 配置网络yum源 RHEL系统本身光盘做成的yum源所提供的软件包有限,在实际使用过程中经常会出现缺包的现象,本文中以CentOS源作为替代,CentOS的软件包和RHE ...

  2. MySQL锁小结

    锁的作用:避免并发请求时对同一个数据对象同时修改,导致数据不一致.   怎么加锁: 1.事务T1在对某个数据对象R1操作之前,先向系统发出请求,对其加锁L1. 2.之后,事务T1对该数据对象R1有了相 ...

  3. Android Support v4,v7,v13的区别和应用场景

    android-support-v4 是谷歌推出的兼容包,最低兼容Android1.6的系统,里面有类似ViewPager等控件.ViewPager在Android 1.6以下的版本是不自带的,所以要 ...

  4. c++参数传递的三种方式

    一般来说C++中参数传递有三种方式:值传递.指针传递.引用传递 1.值传递——传值 值传递是最常见的一种参数传递的方式,但是对初学者来说也最容易出错.如下例: #include<iostream ...

  5. Mysql常见的引擎

    常用的引擎是:Innodb和Myiasm这两种引擎: innodb: 提供了对事务的ACID操作,还提供了行级锁和外键约束,,他的优势就是处理大量数据,在msql启动的时候,首先会建立一个缓存池,主要 ...

  6. linux下jdk的安装配置

    1.下载jdk:地址 选中你选择的版本,下载linux版本对应你系统的32位或64位. 我这里选择的是64位. 2.使用你的ssh直连工具把安装包丢到/usr/local/目录下 3.解压安装jdk ...

  7. Android Studio项目中三种依赖的添加方式

    通常一个AS项目中的依赖关系有三种,一是本地依赖(主要是对本地的jar包),二是模块依赖,三是远程依赖:添加这些依赖的目的在于上我们想要在项目的某一个模块中使用其中的功能,比如okttp这个网络框架库 ...

  8. AMD、CMD和CommonJS规范(转)

    CommonJS规范  CommonJS是在浏览器环境之外构建JavaScript生态系统为目标产生的项目,比如服务器和桌面环境中.CommonJS规范是为了解决JavaScript的作用域问题而定义 ...

  9. Vue源码学习三 ———— Vue构造函数包装

    Vue源码学习二 是对Vue的原型对象的包装,最后从Vue的出生文件导出了 Vue这个构造函数 来到 src/core/index.js 代码是: import Vue from './instanc ...

  10. datatable 默认按某字段排序

    "columns": [ { data: null}, { data: 'name'}, { data: 'birthday'} ], "order": [[ ...