谁能解释关于后叉

谁能解释关于后叉

本文介绍了谁能解释关于后叉'文件描述'一个简单的说明()?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在UNIX环境高级编程,第二版,由理查德·史蒂文斯。

In "Advanced Programming in the Unix Environment", 2nd edition, By W. Richard Stevens.

第8.3节fork函数。

Section 8.3 fork function.

下面的描述:

这父和子共享相同的文件偏移量,它是重要的。

It is important that the parent and the child share the same file offset.

考虑到派生一个子处理,然后等待子来完成。假设这两个进程写到标准输出作为其正常处理的一部分。如果父具有重定向(由一个壳,也许)其标准输出是至关重要的父文件偏移由儿童在儿童写到标准输出进行更新。

Consider a process that forks a child, then waits for the child to complete. Assume that both processes write to standard output as part of their normal processing. If the parent has its standard output redirected (by a shell, perhaps) it is essential that the parent's file offset be updated by the child when the child writes to standard output.

[1。这是什么意思?如果父母的STD输出重定向到一个文件1为例,那么孩子应该更新后的孩子写的东西?父母原STD输出偏移或重定向输出中(即文件1)偏移?不能在后,对吗?]

[1. What does it mean? if parent's std output is redirected to a 'file1' for example, then what should child update after child writes? parent's original std output offset or redirected ouput(i.e file1) offset? Can't be the later, right?]

[2。更新是怎么做的?由子明确,由操作系统隐式地描述符文件本身?叉后,我认为家长和孩子去自己的方式和拥有自己的文件描述符副本。那么,如何子更新偏移父方?]

[2. How is the update done? by child explicitly, by OS implicitly, by files descriptor itself? After fork, i thought parent and child went their own ways and has their own COPY of file descriptor. So how does child update offset to parent side?]

在这种情况下,儿童可以写入而父正在等待它的标准输出;对孩子后,家长可以继续写下去标准输出,知道它的输出将被附加到任何孩子写道。如果家长和孩子没有共享相同的文件偏移量,这种类型的互动将更加难以实现,并且需要由家长明确的行动。

In this case, the child can write to standard output while the parent is waiting for it; on completion of the child, the parent can continue writing to standard output, knowing that its output will be appended to whatever the child wrote. If the parent and the child did not share the same file offset, this type of interaction would be more difficult to accomplish and would require explicit actions by the parent.

如果双方父母和孩子写同一个描述符,没有任何形式的同步,例如,具有为孩子父母的等待,它们的输出将被混合(假设它是这样的叉前开一个描述符)。虽然这是可能的,这不是正常的操作模式。

If both parent and child write to the same descriptor, without any form of synchronization, such as having the parent wait for the child, their output will be intermixed (assuming it's a descriptor that was open before the fork). Although this is possible, it's not the normal mode of operation.

有两个正常的情况下叉式后处理的描述符。

There are two normal cases for handling the descriptors after a fork.


  1. 家长等待孩子来完成。在这种情况下,家长不需要做其描述任何东西。当孩子终止,任何孩子读或共享描述致函将会有自己的文件偏移相应的更新。

  1. The parent waits for the child to complete. In this case, the parent does not need to do anything with its descriptors. When the child terminates, any of the shared descriptors that the child read from or wrote to will have their file offsets updated accordingly.

无论是家长和孩子走自己的方式。这里,叉后,父关闭,它不需要的描述符,和孩子做同样的事情。这样一来,无论是与其他的开放描述干扰。这种情形往往是与网络服务器的情况。

Both the parent and the child go their own ways. Here, after the fork, the parent closes the descriptors that it doesn't need, and the child does the same thing. This way, neither interferes with the other's open descriptors. This scenario is often the case with network servers."

[3。当调用fork()的,我所不解的是,孩子得到了什么样的父母,文件描述符的副本在这种情况下,和做它的事。如果有任何偏移量改变文件描述符的父母与孩子分享,那只能是因为描述记得偏移本身。是吗?]

[3. When fork() is invoked, all i understand is that child get a COPY of what parent has, file descriptor in this case, and does its thing. If any offset changes to file descriptor that parent and child share, it can only be because the descriptor remember the offset itself. Am i right?]

对不起我是一种新的概念。

Sorry I am kind of new to the concepts.

任何帮助吗?谢谢你。

推荐答案

这在文件描述符,这是该进程在其读取和写入呼叫识别使用一个小的整数区分是很重要的该文件,并在文件说明,这是内核的结构。文件偏移量是文件描述的一部分。它生活在内核中。

It's important to distinguish between the file descriptor, which is a small integer that the process uses in its read and write calls to identify the file, and the file description, which is a structure in the kernel. The file offset is part of the file description. It lives in the kernel.

作为一个例子,让我们使用这个程序:

As an example, let's use this program:

#include <unistd.h>
#include <fcntl.h>
#include <sys/wait.h>

int main(void)
{
    int fd;

    fd = open("output", O_CREAT|O_TRUNC|O_WRONLY, 0666);

    if(!fork()) {
        /* child */
        write(fd, "hello ", 6);
        _exit(0);
    } else {
        /* parent */
        int status;

        wait(&status);
        write(fd, "world\n", 6);
    }
}

(所有错误检查已被省略)

(All error checking has been omitted)

如果我们编译这个程序,称之为你好,像这样运行:

If we compile this program, call it hello, and run it like this:

./hello

这里会发生什么:

here's what happens:

该程序打开输出文件,创建它,如果不存在的话,或将其截断至零大小,如果它确实存在。内核创建一个文件描述(在Linux内核中,这是一个结构文件),并将其与调用进程(最低的非负整数尚未文件描述符在该进程的文件描述符表使用)。文件描述符返回,并在程序中分配给 FD 。为了讨论的方便假设 FD 3

The program opens the output file, creating it if it didn't exist already or truncating it to zero size if it did exist. The kernel creates a file description (in the Linux kernel this is a struct file) and associates it with a file descriptor for the calling process (the lowest non-negative integer not already in use in that process's file descriptor table). The file descriptor is returned and assigned to fd in the program. For the sake of argument suppose that fd is 3.

程序调用fork()。新的子进程得到了的复制的母公司的文件描述符表,但该文件的描述是不可复制的。在这两个进程文件表条目编号3指向同一结构文件

The program does a fork(). The new child process gets a copy of its parent's file descriptor table, but the file description is not copied. Entry number 3 in both processes' file tables points to the same struct file.

父进程等待,而子进程写入。孩子的写入导致上半年的hello world \\ n被存储在文件中,并提出该文件由6偏移文件偏移是在结构文件

The parent process waits while the child process writes. The child's write causes the first half of "hello world\n" to be stored in the file, and advances the file offset by 6. The file offset is in the struct file!

孩子退出时,父母的等待()完成后,和父母写道,利用FD 3这仍然是与有它的文件偏移更新相同的文件描述相关联通过孩子的的write()。因此消息的后半部分被存储的的第一部分,而不是覆盖它,因为它会做如果父有文件的零点偏移,这将是该情况下,如果在文件描述并不分享。

The child exits, the parent's wait() finishes, and the parent writes, using fd 3 which is still associated with the same file description that had its file offset updated by the child's write(). So the second half of the message is stored after the first part, not overwriting it as it would have done if the parent had a file offset of zero, which would be the case if the file description was not shared.

最后父退出,内核看到的结构文件是不再使用并释放它。

Finally the parent exits, and the kernel sees that the struct file is no longer in use and frees it.

这篇关于谁能解释关于后叉'文件描述'一个简单的说明()?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-03 22:17