Date: Thu, 4 Aug 2005 12:25:28 +0400 From: Andrey Chernov <ache@FreeBSD.ORG> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: Maxim.Sobolev@portaone.com, Dan Nelson <dnelson@allantgroup.com>, "current@freebsd.org" <current@FreeBSD.ORG> Subject: Re: Sub-optimal libc's read-ahead buffering behaviour Message-ID: <20050804082527.GA22992@nagual.pp.ru> In-Reply-To: <20050804075711.GB271@cirb503493.alcatel.com.au> References: <42F0CCD5.9090200@portaone.com> <20050803150117.GD93405@dan.emsphone.com> <42F0E9B2.9080208@portaone.com> <20050804060251.GA21228@nagual.pp.ru> <20050804063908.GA21871@nagual.pp.ru> <20050804075711.GB271@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 04, 2005 at 05:57:11PM +1000, Peter Jeremy wrote: > >In case SEEK_CUR still uses > >the buffer, it probably should not for character device. As I look at the fseek code now, _any_ non-regular file seek is not optimized, which is right things (and BSD traditional). > I can't see any reason for the current stdio behaviour: > - If you're accessing a device with "magic" behaviour then it's not safe > to read(2) 4KB (or whatever) when userland asks to fread(3) 512 bytes. It is safe to read more. You may hit EOF, but it handles by stdio internally. It is not safe to read again from the buffer. In that case fseek to needed position helps to re-read. > - If the device doesn't have "magic" behaviour then you can just seek > within the stdio buffer. > > That said, I've seen similar behaviour on other systems so it could be > a subtle side-effect of POSIX. It is traditional BSD behaviour. Compare this place with less touched NetBSD fseeko.c f.e. -- http://ache.pp.ru/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050804082527.GA22992>