Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>At the lowest level, on POSIX platforms, open files are represented by "descriptors" in userspace. A file descriptor is just an integer which is unique across open files at any given time. The descriptor is used to identify which open file an operation should be applied to when asking the kernel to actually perform that operation. So, <code>read(0, charptr, 1024)</code> does a read from the open file which is associated with the descriptor <code>0</code> (by convention, this will probably be a process's standard input).</p> <p>As far as userspace can tell, the only parts of a file that are loaded into memory are those that are required to satisfy an operation like <code>read</code>. To read bytes from the middle of a file, another operation is supported - ''seek''. This tells the kernel to reposition the offset in a particular file. The next <code>read</code> (or <code>write</code>) operation will work with bytes from that new offset. So <code>lseek(123, 100, SEEK_SET)</code> repositions the offset for the file associated with <code>123</code> (a descriptor value I just made up) to the 100th byte position. The next read on <code>123</code> will read starting from that position, not from the beginning of the file (or wherever the offset was previously). And any bytes not read don't need to be loaded into memory.</p> <p>There is a little more complexity behind the scenes - the disk usually can't read less than a "block" which is typically a power of two around 4096; the kernel probably does extra caching and something called "readahead". But these are optimizations, and the basic idea is what I described above.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload