Linux下C语言中的文件描述符示例

Question

我编写了以下代码，以更好地理解c语言中的文件描述符。

int main(){

    int p[2], n=7, r;

    pipe(p);

    if(fork() == 0){
            //close(p[0]);
            printf("child: %d\n", getpid());
            write(p[1], &n, sizeof(n));

    }

    //the below code will be executed by parent and child process
    printf("shared print: %d\n", getpid());
    r = read(p[0], &n, sizeof(n));
    printf("shared print, value from child: %d, pid: %d\n", n, getpid());
    printf("read result: %d, pid: %d\n", r, getpid());
}

我得到以下结果：

shared print: 332
child: 333
shared print: 333
shared print, value from child: 7, pid: 332
read result: 4, pid: 332

如果孩子的第一行没有注释，我会得到：

shared print: 339
child: 340
shared print: 340
shared print, value from child: 7, pid: 339
shared print, value from child: 7, pid: 340
read result: 4, pid: 339
read result: -1, pid: 340

有谁能解释我关闭读取描述符时发生的情况？ 我的期望是子块下的代码每次都由两个进程执行，但这只有在child中启用close（p [0]）时才会发生。 为什么呢

Answer 1

您有一个竞争条件：两个进程都在调用read ，但是其中一个只有足够的数据。

如果父母先阅读，然后孩子会上吊-但由于它在后台，您可能没有注意到。

如果孩子先阅读，父母会上吊，您会注意到。

使用strace -f ./foo可以显示正在发生的事情：

execve("./foo", ["./foo"], [/* 52 vars */]) = 0
// loading libraries
brk(NULL)                               = 0x55fd6dc09000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcf9ebce000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=168993, ...}) = 0
mmap(NULL, 168993, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fcf9eba4000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\4\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1689360, ...}) = 0
mmap(NULL, 3795296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fcf9e60f000
mprotect(0x7fcf9e7a4000, 2097152, PROT_NONE) = 0
mmap(0x7fcf9e9a4000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x195000) = 0x7fcf9e9a4000
mmap(0x7fcf9e9aa000, 14688, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fcf9e9aa000
close(3)                                = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcf9eba2000
arch_prctl(ARCH_SET_FS, 0x7fcf9eba2700) = 0
mprotect(0x7fcf9e9a4000, 16384, PROT_READ) = 0
mprotect(0x55fd6c47b000, 4096, PROT_READ) = 0
mprotect(0x7fcf9ebd1000, 4096, PROT_READ) = 0
munmap(0x7fcf9eba4000, 168993)          = 0
pipe([3, 4])                            = 0
// the fork() function actually calls `clone` these days
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fcf9eba29d0) = 6640
strace: Process 6640 attached
[pid  6639] getpid()                    = 6639
// the processes are running at the same time, so you get a lot of <unfinished ...> even for short-duration syscalls
[pid  6640] getpid( <unfinished ...>
[pid  6639] fstat(1,  <unfinished ...>
[pid  6640] <... getpid resumed> )      = 6640
// fstat is needed before the first write, to know whether stdout should be line-buffered or fully-buffered
// this happens in *both* processes since you didn't do any writes before fork()ing
// (and if you did, you would have to call fflush)
[pid  6639] <... fstat resumed> {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
[pid  6640] fstat(1,  <unfinished ...>
// brk is used to implement malloc, for stdout's buffer
[pid  6639] brk(NULL <unfinished ...>
[pid  6640] <... fstat resumed> {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
[pid  6639] <... brk resumed> )         = 0x55fd6dc09000
[pid  6640] brk(NULL <unfinished ...>
[pid  6639] brk(0x55fd6dc2a000 <unfinished ...>
[pid  6640] <... brk resumed> )         = 0x55fd6dc09000
[pid  6639] <... brk resumed> )         = 0x55fd6dc2a000
[pid  6640] brk(0x55fd6dc2a000 <unfinished ...>
// note mixed output since strace and the program are writing to the same place
// note also that if output wasn't to a TTY, buffering would delay the writes.
[pid  6639] write(1, "shared print: 6639\n", 19shared print: 6639
 <unfinished ...>
[pid  6640] <... brk resumed> )         = 0x55fd6dc2a000
[pid  6639] <... write resumed> )       = 19
[pid  6639] read(3,  <unfinished ...>
[pid  6640] write(1, "child: 6640\n", 12child: 6640
) = 12
// little-endian
[pid  6640] write(4, "\7\0\0\0", 4)     = 4
// parent happens to win the read - often the case with multiple CPUs
[pid  6639] <... read resumed> "\7\0\0\0", 4) = 4
[pid  6640] getpid( <unfinished ...>
[pid  6639] getpid( <unfinished ...>
[pid  6640] <... getpid resumed> )      = 6640
[pid  6639] <... getpid resumed> )      = 6639
[pid  6640] write(1, "shared print: 6640\n", 19shared print: 6640
 <unfinished ...>
[pid  6639] write(1, "shared print, value from child: "..., 45shared print, value from child: 7, pid: 6639
 <unfinished ...>
[pid  6640] <... write resumed> )       = 19
[pid  6639] <... write resumed> )       = 45
// losing read here
[pid  6640] read(3,  <unfinished ...>
[pid  6639] getpid()                    = 6639
[pid  6639] write(1, "read result: 4, pid: 6639\n", 26read result: 4, pid: 6639
) = 26
// parent finishes - outside of strace, this looks like everything is done
[pid  6639] exit_group(0)               = ?
[pid  6639] +++ exited with 0 +++
// parent interrupted ... child is still waiting
// (although since ^C applies to the whole process group, the child happens to get interrupted sometime after strace stops paying attention - without strace, I wouldn't've given it the signal)
^Cstrace: Process 6640 detached

对比一下，如果添加else sleep(1)会发生什么，以便孩子有一些时间运行：

// startup omitted
pipe([3, 4])                            = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f469a2149d0) = 25597
strace: Process 25597 attached
[pid 25596] nanosleep({tv_sec=1, tv_nsec=0},  <unfinished ...>
[pid 25597] getpid()                    = 25597
[pid 25597] fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
[pid 25597] brk(NULL)                   = 0x555f092f8000
[pid 25597] brk(0x555f09319000)         = 0x555f09319000
[pid 25597] write(1, "child: 25597\n", 13child: 25597
) = 13
// note that writing-then-reading a pipe in the same thread is only safe if at most PIPE_BUF bytes, which is guaranteed to be 512 by POSIX, but is 4096 on Linux
[pid 25597] write(4, "\7\0\0\0", 4)     = 4
[pid 25597] getpid()                    = 25597
[pid 25597] write(1, "shared print: 25597\n", 20shared print: 25597
) = 20
[pid 25597] read(3, "\7\0\0\0", 4)      = 4
[pid 25597] getpid()                    = 25597
[pid 25597] write(1, "shared print, value from child: "..., 46shared print, value from child: 7, pid: 25597
) = 46
[pid 25597] getpid()                    = 25597
[pid 25597] write(1, "read result: 4, pid: 25597\n", 27read result: 4, pid: 25597
) = 27
// child finishes first
[pid 25597] exit_group(0)               = ?
[pid 25597] +++ exited with 0 +++
<... nanosleep resumed> {tv_sec=0, tv_nsec=998890543}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=25597, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
restart_syscall(<... resuming interrupted nanosleep ...>) = 0
getpid()                                = 25596
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
brk(NULL)                               = 0x555f092f8000
brk(0x555f09319000)                     = 0x555f09319000
write(1, "shared print: 25596\n", 20shared print: 25596
)   = 20
// parent still blocking when I press ^C
read(3, ^Cstrace: Process 25596 detached
 <detached ...>

还要注意，您可以将管道设置为非阻塞模式，但随后必须处理EAGAIN （通常通过调用select系列中的某项），因此在这里无济于事：

int flags = fcntl(fd, F_GETFL, 0);
fcntl(fd, F_SETFL, flags | O_NONBLOCK);

Answer 2

如果在子级中关闭p [0]，则子级的read（）调用将失败，并且您将保留旧值（7）。 如果未在子级中关闭p [0]，则子级的read（）调用会阻塞，因为没有要读取的内容（父级读取了所有数据），但是由于p [1]没有关闭，因此也不是允许read（）返回的EOF。

因此，基本上，如果未在子级中关闭p [0]，则子级将停留在read（）调用上。