OSDev.org

Posted: **Mon Nov 25, 2013 10:27 am**

Or because the OS has only pread, which was the initial question.

If you have both, then you can use this information as a hint indeed. You could as well do that with a flag if you only have a pread()-style function (or a general hint on the file descriptor that says whether the access is mostly sequential) and want to have the hint.

mrstobbe wrote:My point is OS's can do that (and quite frankly should if they aren't already). Seeking someplace is an immediate indicator that, as program, you intend to do something there. If the file's been opened as read only, you know exactly what they plan to do there.

Sure, the very next thing will be a read. Still not a good argument for having a separate seek function. It only allows you to start a prefetch before the application issues the second syscall that isn't even necessary if you have a combined pread.

I think having a seek/read pair is convenient anyway, but it's not really necessary for anything.

Posted: **Tue Nov 26, 2013 12:27 am**

Kevin wrote:
mrstobbe wrote:My point is OS's can do that (and quite frankly should if they aren't already). Seeking someplace is an immediate indicator that, as program, you intend to do something there. If the file's been opened as read only, you know exactly what they plan to do there.
Sure, the very next thing will be a read. Still not a good argument for having a separate seek function. It only allows you to start a prefetch before the application issues the second syscall that isn't even necessary if you have a combined pread.

You don't think people do this?

Code: Select all

fd = open("whatever.bin", O_RDONLY);
if (fd == -1)
   whatever();
lseek(fd, some_offset_of_some_sort, SEEK_SET);
[insert a bunch of arbitrary setup code here]
read(fd, whatever, and_whatever);

I'm not saying it's good practice, I'm saying that it most certainly happens all the time.

Posted: **Tue Nov 26, 2013 4:52 am**

mrstobbe wrote:I'm saying that it most certainly happens all the time.

Because it's a standard

But seriously, passing around either FILE*'s or FDs and integer pointers across the app so that parsers of anything nontrivial maintain the correct offset in the file across the whole bunch of method calls involved is begging for simplification to one handle argument and wrapper functions that maintains the offset for you, regardless of read or pread or both being the actual system call.

OSDev.org

Why still seek and read?

Re: Why still seek and read?

Re: Why still seek and read?

Re: Why still seek and read?