Why still seek and read?

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Kevin
Member
Member
Posts: 1071
Joined: Sun Feb 01, 2009 6:11 am
Location: Germany
Contact:

Re: Why still seek and read?

Post by Kevin »

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.
Developer of tyndur - community OS of Lowlevel (German)
mrstobbe
Member
Member
Posts: 62
Joined: Fri Nov 08, 2013 7:40 pm

Re: Why still seek and read?

Post by mrstobbe »

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.
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: Why still seek and read?

Post by Combuster »

mrstobbe wrote:I'm saying that it most certainly happens all the time.
Because it's a standard :wink:

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.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Post Reply