Processes and File Handles

$ pmap # memory mappings

True confessions: I cheated here.

True confessions: I cheated here.

Let’s imagine we caught bash during startup when it is reading its configuration parameters.

How do top, ps, pmap, lsof, and other process examination utilities gather information?
Linux reuses the file abstraction for this purpose.

Threads save processor state.
Address spaces map the addresses used by processes (virtual addresses) to real memory addresses (physical addresses).
Files map offsets into a file to blocks on disk.
File-like objects look like files to a process but are not actually stored on disk and may not completely obey file semantics.
- You can’t seek on a network socket or open certain network-mounted files.
Processes organize these other operating system abstractions.

For today’s material being precise about how processes use files becomes important.

The file descriptor that processes receive from open() and pass to other file system system calls is just an int, an index into the process file table.
That int refers to a file handle object maintained by the kernel.
That file handle object contains a reference a separate file object also maintained by the kernel.
Which then is mapped by the file system to blocks on disk.
So three levels of indirection:
- file descriptor → file handle.
- file handle → file object.
- file object → blocks on disk.
Why?

The additional level of indirection allows certain pieces of state to be shared separately.

File descriptors are private to each process.
File handles are private to each process but shared after process creation.
- File handles store the current file offset, or the position in the file that the next read will come from or write will go to. File handles can be deliberately shared between two processes.
File objects hold other file state and can be shared transparently between many processes.