fork和资源的关系

nuclearweapon

Post by zhllg
这么说吧
一开始的fork的实现是不复制页表的
而是马上给子进程分配物理内存，页表自然不同
在那个时候的系统里，楼主的程序显示出的两个地址也是相同的
你明白了么

linux好像不是吧 现在的fork好像也都不是这样的吧
你在用这样的系统做过试验吗？这个我真的没用过
我想楼主也没有用吧！

不好意思刚开始看一些内核，大侠多执教

zhllg

现在Linux的fork使用了Copy-On-Write，你自己不也说了
其实用不着试验
不管fork是怎么实现的，它的效果对于用户程序来说都应该是一样的
而这个程序只能体现fork的效果

指教不敢当，交流吧

realtang

在内核中，每个进程都有自己的线性区，虽然都有相同的虚地址，但所对应的物理页其实是不同的。Linux在执行fork系统调用时，并没有立即分配新的页给子进程。而是复制了父进程的进程描述符等相关的资源，重新分配一个PID给子进程，并将字进程设为可运行。并且将父进程的页标为只读。这以后，如果父进程或者子进程有写的操作。将会产生一个写保护的异常，这个异常会导致缺页异常中断处理程序的运行。这时Linux会分配一个新的页，当然这个页也可能是从Linux的页面高速缓存中直接拿来用的。这个页就给了那个产生异常的进程用了，那么被复制的页就归另外一个进程使用。这时这两个页的属性就都是可写的了。

nuclearweapon

你没有试验，就别说了以前的fork了。

即便楼主的程序在以前的fork下执行，如果子进程和父进程arry的地址相同，那也是由于页表的组织结构相同的原因。

我认为  ”这里“   虚地址相同就是因为复制页表，

要是这里虚地址不一样，结果如何？？
请回答这个问题！



所以说，这里必须提到复制页表。

请您在反驳我的任何观点的时候先回答这个问题，谢谢！


交流第一

zhllg

to nuclearweapon:

首先，还是得承认你说的有一定道理
页表代表虚拟地址到物理地址的映射
页表一样代表的是：一样的虚拟地址对应到一样的物理地址
fork要保证的是父子进程虚拟地址空间的布局一样（text，data，heap，mmapped file，stack，这些vma的起止地址都一样，你说的组织结构恐怕就是这个意思吧），其内容也相同。现代Linux的fork，如果子进程不写入父进程地址空间任何数据的话，仅通过复制页表就可以保证布局一样内容相同。所以说你的话有一定道理。不过楼主的例子里，子进程必会得到独立的stack的物理页，而且打印地址时已经得到了独立的stack的物理页。在其获得独立的物理页之时复制页表已经完成，是fork的其他机制在继续维持父子布局一样内容相同。所以复制页表，也不是虚拟地址一样这个现象的唯一原因。

还有页表是全部复制的(see dup_mmap() in kernel/fork.c)，然后如果后来需要改变某个页的内容时再为子进程分配新的物理内存页。楼主的例子里子进程的stack和heap段都是要重新分配物理页的，因为有函数调用和array指向的内存区域的内容的改变。

讽刺的是，你说不共享stack空间，但array是本地变量(auto)位于stack里，而你偏偏一直以复制页表作为证明虚拟地址空间相同的依据。

无论如何我还是坚持一点，就是解释楼主的疑问不必这么深入，楼主对进程地址空间是彼此独立的这一点还不明确，这时就解释fork实现的细节，会让人更晕的。一步一步的来吧。

虚拟地址一定相同
假设它不相同的想法一定不要有
这正是fork要保证的，fork的使命就是这样，不管在什么UNIX系统里
解释这一点足够了

如果按照你的解释方式
我还可以说其实楼主看到的只是打印出的地址相同
这个成因是：
首先看汇编代码，打印地址的汇编代码(节选)的一种可能如下：（假设stack boundary = 2）
.section .rodata
.LC0:
    .string "child array:%x,%s\n"
...
.section .text
...
    movl    -4(%ebp), %eax
    movl    %eax, 8(%esp)
    movl    %eax, 4(%esp)
    movl    $.LC0, (%esp)  
    call    printf
rodata段和text段都是只读的
复制页表保证了父子进程这两个段一样
显然还要保证寄存器(%ebp)的值一样
fork会复制保存于task_struct里的cpu状态信息(struct thread_struct thread)所以寄存器的值也一样
自然打印出的结果也一样

rickxbx

试想一下,如果不复制页表,是否虚拟地址就可以不一样了呢?
fork只有语义上的约束,并没有实现上的约束.在实现的时候,完全可以不复制页表嘛,
不要拘泥于"这里"了,"这里"只是一种实现,在某些不能使用cow技术的平台上自然是不复制页表的.至于有没有,就不得而知了,但这说明了一点,复制页表与父子进程的某个变量的虚拟地址是否相同理论上并无直接关系.

nuclearweapon

Post by zhllg
to nuclearweapon:

讽刺的是，你说不共享stack空间，但array是本地变量(auto)位于stack里，而你偏偏一直以复制页表作为证明虚拟地址空间相同的依据

复制了页表就一定共享吗？我可没有说！这是你理解的不要给我扣帽子 嘻嘻

你们想想，子进程和父进程的页表都一样了（在子进程写之前），虚地址要是不一样的话，那么用户读能读取到相同的内容吗？当然不能！！

这难道还不是虚地址一样的原因吗？

Post by rickxbx

试想一下,如果不复制页表,是否虚拟地址就可以不一样了呢?
fork只有语义上的约束,并没有实现上的约束.在实现的时候,完全可以不复制页表嘛,
不要拘泥于"这里"了,"这里"只是一种实现,在某些不能使用cow技术的平台上自然是不复制页表的.至于有没有,就不得而知了,但这说明了一点,复制页表与父子进程的某个变量的虚拟地址是否相同理论上并无直接关系.

说什么话，回什么帖子都是有context的
“在楼主这个问题里”（我相信他也是在linux系统里）
复制页表与父子进程的某个变量（auto类型）的虚拟地址是否相同理论上有直接关系.

我不清楚您回这些是有意义？
我不相信，在linux编程这个版面了这样写什么错！


呵呵－

zhllg

你的错（如果你一定要承认这些是你的错的话）在于：
你的这个解释对于楼主来说基本相当于没有解释：知道什么叫页表的人不会问楼主这样的问题
你的这个观点给人以错误的印象：复制页表->虚拟地址相同，不明就里的人或许会以为不复制页表虚拟地址就会不同。而事实是不管fork具体实现细节如何，虚拟地址一定相同。
严格的说这个观点本身“在这里”也是不正确的：前面已经分析了，因为打印地址之前，有一个printf的调用，调用函数时需要改变堆栈(参数，返回地址)。也就是说打印之时子进程已经向stack写入数据了。也就是说这时页表已经不一样了。而且要打印出一样的地址，还需要复制task_struct（里面含有cpu状态－寄存器的值）

ps：复制页表的目的就是共享物理内存，如果你的理解不是这样，那么很遗憾你的理解是错的

rickxbx

Post by nuclearweapon

说什么话，回什么帖子都是有context的
“在楼主这个问题里”（我相信他也是在linux系统里）
复制页表与父子进程的某个变量（auto类型）的虚拟地址是否相同理论上有直接关系.

我不清楚您回这些是有意义？
我不相信，在linux编程这个版面了这样写什么错！


呵呵－

我那样说,只是想让你明白一件事:复制页表与虚拟地址相同没有必然的联系.
你一直强调"这里"无非就是想说,"这里"是复制页表的,没错,是复制了页表,可是复制页表究竟与虚拟地址相同有无关系却不需要拘泥于"这里",因为很明显啊,现在就有两个观点:
1. 某个因素是某个结果的成因
2. 某个因素与这个结果没关系
我们只要说明没有这个因素,而是用他的反面代替,其他一切照旧(这一点很重要)也能产生这样的结果就能说明事实上这个因素并不是这个结果的成因了,这个因素只是一个可有可无,可正可负的因素,不知道兄弟是否明白

ps:我之所以想到要这么解释,主要还是因为你对zhllg兄的正面解释似乎并不接纳,不得已而为之

一杯矿泉水

新人随便说说，
我个人感觉这里，复制页表是个很重要的原因啊！