Should fseek() call lseek()?

[Erik E. Rantapaa]

I was testing a Perl script on both a Sun and a Linux box and
found out that the SunOS fseek() does not always cause the stdio file
buffer to get filled, and moreover calls lseek() with exactly the
same offset that was passed to fseek().

Under Linux, however, an fseek() will call lseek() with an offset which
is always a multiple of 4096 (or something like that) and may cause the
the stdio buffer to get filled.

There are pros and cons to both implementations. However, when writing
Perl scripts, Sun's method allows one to mix 'seek' and 'sysread' calls.
Currently, Perl's 'seek' function calls fseek() and there is no access
to lseek().

This is really important to me because I want to use Perl, yet I also want
to control how my I/O is done. Having 'seek' perform a read will not
work for me.

So some questions are: should Linux be changed to emulate the Sun behavior?
(how do other operating systems handle this?) Should Perl be changed
to always call lseek() after fseek()? Should we add an interface to
lseek() for Perl?

--
Erik E. Rantapaa -- rant...@math.umn.edu -- <put something here>

[Jan Nicolai Langfeldt]

In article <rantapaa....@s6.math.umn.edu>,

Erik E. Rantapaa <rant...@s6.math.umn.edu> wrote:
>I was testing a Perl script on both a Sun and a Linux box and
>found out that the SunOS fseek() does not always cause the stdio file
>buffer to get filled, and moreover calls lseek() with exactly the
>same offset that was passed to fseek().
>
>Under Linux, however, an fseek() will call lseek() with an offset which
>is always a multiple of 4096 (or something like that) and may cause the
>the stdio buffer to get filled.

1024 in my experience. The exact behaviour you describe should not be
evident in linux libc-4.6.20 (though I have not checked), sometime
after libc-4.5.26 came out I worked some on the long startup time of
xdvi on linux nfs clients and Cygnus optimized the fseek routine some
(fewer lseeks).

>There are pros and cons to both implementations. However, when writing
>Perl scripts, Sun's method allows one to mix 'seek' and 'sysread' calls.
>Currently, Perl's 'seek' function calls fseek() and there is no access
>to lseek().

If perls seek uses fseek and you use perls seek then you should _not_
use sysread under any circumstances. Mixing stdio and system call io
(and rely on the stdio implementation to do the Right Thing) is evil
and will only bring you grief. You risk that your perl script breaks
when libc is updated, or when moving to new platforms.

>So some questions are: should Linux be changed to emulate the Sun behavior?
>(how do other operating systems handle this?) Should Perl be changed
>to always call lseek() after fseek()? Should we add an interface to
>lseek() for Perl?

Adding a lseek interface to perl would seem the only reliable choice.

Nicolai Langfeldt. ja...@ifi.uio.no. http://www.ifi.uio.no/~janl/
Visualize free Unix: http://www.linux.org/ http://www.linux.org.uk/
"And when a child is born into this world/It has no concept/
(of) The tone of skin (it) is living in" Y.N'Dour-N.Cherry

[Nick Holloway]

In <rantapaa....@s6.math.umn.edu> rant...@s6.math.umn.edu (Erik E. Rantapaa) writes:
> So some questions are: should Linux be changed to emulate the Sun behavior?
> (how do other operating systems handle this?) Should Perl be changed
> to always call lseek() after fseek()? Should we add an interface to
> lseek() for Perl?

I posed this question a while back, when my Perl script that worked
under SunOS failed under Linux.

The general consensus was that you shouldn't mix stdio and syscalls,
and what was needed was for Perl to have a sysseek routine (rather than
changing Linux).

You can fake it using the Perl's syscall builtin (as I did, but can't
find it just now).

--
Nick Holloway | `O O' | Home: Nick.H...@alfie.demon.co.uk
[aka `Alfie'] | // ^ \\ | Work: Nick.H...@parallax.co.uk

[Wayne Scott]

In article <3bb4rl$f...@alfie.demon.co.uk>,

Don't forget:

#!/usr/local/bin/perl

require 5.0;

use POSIX 'lseek';

lseek(...);

It works great!

Wayne

--
-------- |
Wayne Scott P6 Architecture Performance
wsc...@ichips.intel.com Work #: (503) 696-4165