文件描述符存储在过程存储器中的什么位置? [英] where is file descriptor stored in process memory?
问题描述
从执行点调用函数A时，在内部它是指向函数A的地址的JMP语句.因此，当前执行点被保存到堆栈中，PC加载被调用函数的地址A并继续.
When a function A is called from a point of execution, internally it is a JMP statement to the address pointing to function A. So the current point of execution is saved onto the stack, the PC loads the address of the called function A and continues.
要返回到函数调用之后的执行点，功能块应具有相等的压入并弹出堆栈.通常在C中退出函数时，定义的堆栈变量会被销毁(我认为这意味着从堆栈中弹出)，但是我决定在函数中定义一个文件描述符变量.代码如下:
To get back to the point of execution after the function call, the function block should have equal push and pops onto the stack. Normally in C on exiting the function, the stack variables defined are destroyed(which I presume means popped off the stack), but I decided to define a file descriptor variable inside my function. The code is below:
void main() {
printf("In the beginning there was main()\n");
func_call();
printf("func_call complete\n");
while(1);
}
void func_call() {
int fp;
//Opening a file to get handle to it.
fp = open("stack_flush.c", O_RDONLY);
if (fp < 0 ) {
perror("fp could not open stack_flush.c");
return;
}
}
在运行该程序并检查lsof时，我看到退出函数func_call()时，fd仍处于打开状态.
On running this program and checking lsof, I can see that the fd is still open upon exiting the function func_call().
stack_flu 3791 vvdnlt260 0u CHR 136,1 0t0 4 /dev/pts/1
stack_flu 3791 vvdnlt260 1u CHR 136,1 0t0 4 /dev/pts/1
stack_flu 3791 vvdnlt260 2u CHR 136,1 0t0 4 /dev/pts/1
stack_flu 3791 vvdnlt260 3r REG 8,3 526 24660187 /home/vvdnlt260/Nishanth/test_space/stack_flush.c
我检查了Wikipedia条目中的文件描述符，发现了这一点:
I checked the wikipedia entry for file descriptors and I found this:
要执行输入或输出，该进程通过系统调用将文件描述符传递给内核，内核将代表该进程访问文件.该进程无法直接访问文件或inode表.
To perform input or output, the process passes the file descriptor to the kernel through a system call, and the kernel will access the file on behalf of the process. The process does not have direct access to the file or inode tables.
从上面的语句很明显，文件描述符整数值存储在进程内存中，但是尽管它是在函数中定义的，但文件描述符不是函数本地的，因为它在函数退出时不会被删除.
From the above statement it's obvious that the file descriptor integer value is stored in process memory, but although it was defined in a function, the file descriptor was not local to the function as it did not get removed on function exit.
所以我的问题是2折:
1)如果文件描述符是func_call()堆栈的一部分，那么即使未弹出代码，代码如何返回到其函数调用前的执行点?同样在这种情况下，为什么在函数调用存在后仍然存在?
1) If the file descriptor is part of the func_call() stack, then how does the code return to its pre function call execution point although it has not been popped off? Also in this case why does it persist after the function call exists?
2)如果文件描述符不位于func_call()堆栈的一部分，则它位于进程内存中吗?
2) If not part of the func_call() stack where does the file descriptor reside in the process memory?
推荐答案
变量int fd;仅在函数func_call()中可见，该函数执行完毕后，将弹出堆栈，并覆盖内存可能是在输入新功能时.您破坏了指向该文件的某些int值的事实并不意味着您关闭了所述文件.如果您做了类似的事情怎么办:
The variable int fd; is only visible from the function func_call() and after this function finishes executing it will be popped of the stack and the memory will be overwritten probably when a new function is entered. The fact that you destroy some int value pointing to the file does not mean that you close said file. What if you did something like:
int global_fd;
void foo() {
int local_fd = open("bar.txt", O_RDONLY);
global_fd = local_fd;
}
又叫foo()?您希望在foo出口之后不再使用global_fd吗?
And called foo()? Would You expect to not be able to use global_fd anymore afteer foo exits?
在这种情况下，将文件描述符视为指针的指针是很有帮助的，您要求内核为您提供文件，并且它会为您提供一个值，您可以将其用作此特定文件的令牌，这令牌是用来使内核知道read或lseek之类的功能应作用于哪个文件的功能.当令牌传递或破坏时，文件将保持打开状态，就像破坏指针不会释放分配的内存一样.
It is helpful to think in this case of the file descriptor as a of a pointer, You ask the kernel to give You the file, and it gives you a value that You can use as a token for this specific file, this token is what you use to let the kernel know on which file should the function like read or lseek act. When the token is passed around or destroyed the file remains open just as destroying the pointer does not free the allocated memory.
这篇关于文件描述符存储在过程存储器中的什么位置?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
