File handles, file descriptors, and processes and multi-threaded things

This article has been presented to: Http://my.oschina.net/iuranus/blog/330397?fromerr=x1SVuj0Z

File handles (excerpt of some concepts to help understand):

A handle is a unique integer used by wondows to identify objects that are created or used by the application, and Windows uses a variety of handles to identify such as application instances, Windows, controls, bitmaps, GDI objects, and so on. The Windows handle is somewhat like a file handle in the C language.

If you want to know the handle more thoroughly, I can tell you that the handle is a pointer to the pointer. We know that the so-called pointer is a memory address. After the application is started, the objects that make up the program are left in memory. If we simply understand, it seems that we just know the first address of this memory, then we can access the object at any time with this address. But if you really think so, then you're wrong. We know that Windows is a virtual memory-based operating system. In this system environment, the Windows Memory manager often moves objects back and forth in memory to meet the memory needs of various applications. The object being moved means that its address has changed. If the address always changes so, where should we go to find the object?

To solve this problem, the Windows operating system frees up some internal storage addresses for each application to specifically register the address changes in memory for each application object, and the address (the location of the storage unit) itself is unchanged. When the Windows Memory Manager moves the object's location in memory, it stores the address of the new object to the handle. So we just have to remember this handle address to know indirectly where the object is in memory. This address is assigned by the system when the object is loaded (load) and released to the system when the system is unloaded (Unload).

A handle is a unique identity that the operating system assigns to an object when it is generated. The service provided by the operating system can be obtained through a handle. The handle is different from the pointer, and if you get a pointer to an object, you can do whatever you like on this object. So the system does not give you pointers, but gives the user a limit, the identifier of the pointer used to track the object-the handle. It is relatively safe for the system to use handles to provide services out of the way.

Summarize:

1, whether it is a file handle (in Windows concept), or a file descriptor (the concept of Linux), its ultimate purpose is to locate the open files in memory location, but they do not map the same way.

2. The file handle is anchored to a file object, not a file. The file object is the encapsulation of some state and attributes of the file, such as the location of the file to which it was read.

3, about in the process, the thread, this time with the file handle is not good elaboration, you can interpret the file handle into the file descriptor, such as:

Each process has its own separate file descriptor, and opening different files will also have different open File table entries and point to different V-node table entries.

No files are shared at this time, and each descriptor corresponds to a different file.

Different processes open a file more than once, resulting in different opening file table entries, but eventually pointing to the v-node of the same file.

At this point, multiple descriptors can also refer to the same file through different file table entries. For example, this happens if you call the Open function two times with the same filename. The key idea is that each descriptor has its own file location, so the read operation of the different descriptors can fetch data from different locations in the file.

If you open the same file in multiple threads (unlike opening a file in the main thread and passing the FD parameter of Fd=open (file) to the thread), each thread will have its own file descriptor, which, according to the previous key idea, will have its own read location saved, without prejudice.

in-depth understanding of the computer system there are also words: because each process has its own handle storage space, if it is the same process thread, because the same as the I/O multiplexing-based flow, multiple threads run in the context of a single process, Share the entire contents of this process virtual address space, including its code, data, heap, shared libraries, and open files (handles). This should also mean that the process has opened the file, then the thread shares the open file.

If the parent process has opened the file before calling fork, the child process after fork has a copy of the parent process descriptor. The parent-child process shares the same open file collection, and therefore shares the same file location.

This is the same situation as the main thread has open files, and the FD is passed to the startup threads.

Additional attention to the above picture table is explained below:

File handles, file descriptors, and processes and multi-threaded things