Is there any reasons to not use "mmap" to read files?

[Steven Schveighoffer]

On 2/12/22 10:13 PM, H. S. Teoh wrote:
> On Sat, Feb 12, 2022 at 07:01:09PM -0800, Ali Çehreli via Digitalmars-d wrote:
>> On 2/12/22 05:17, rempas wrote:
>>
>>> a system call every single time
>>
>> I have a related experience: I realized that very many ftell() calls
>> that I were making were very costly. I saved a lot of time after
>> realizing that I did not need to make the calls because I could
>> maintain a 'long' variable to keep track of where I was in the file.
>>
>> I assumed ftell() would do the same but apparently not.
> [...]
> 
> I think the reason is the ftell involves an OS API call, because fread()
> uses the underlying read() syscall which reads from where it left off
> last, and there could be multiple threads reading from the same file
> descriptor, so the only way for fseek/ftell to work correctly is via a
> syscall into the kernel.  Obviously, this would be expensive, as it
> would involve a kernel context-switch as well as acquiring and releasing
> a lock on the file descriptor.

`ftell` does not *need* to do a system call to get the current file 
position. But otherwise it has to store the offset of the file somewhere 
(which it does not). In fact, if you move the file pointer underneath 
(by using another thread to read from it, or e.g. with `lseek`), you 
will completely invalidate what `ftell` returns (try it!)

What `ftell` basically does is to a system call to `lseek` to get the 
current file position, then subtracts the difference between the current 
buffer offset and the buffer size.

This is not the same for `fgetc`. That only depends on the buffer, and 
not anything from the OS (after the buffer is filled).

-Steve