Date: Thu, 5 Nov 1998 20:01:20 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Joseph Koshy <jkoshy@FreeBSD.ORG> Cc: dag-erli@ifi.uio.no (Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?= ), cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: sendfile.2 (was Re: cvs commit: ...) Message-ID: <199811060401.UAA00767@apollo.backplane.com> References: <199811060342.TAA11021@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> would be to actually use it in the stdio library for read operations
:> on plain files: [f]getc(), fgets(), and fread(). The only difficulty
:> here is in how to deal with file truncation issues, since accessing
:> mmap'd pages beyond the file's size will segfault.
:
:For what its worth, the SFIO library from AT&T already supports
:this. I don't remember what copyright it is released under though.
:
:Koshy
:<jkoshy@freebsd.org>
Well, it isn't that difficult to do... it would take maybe 20 minutes
to implement. A simple MAP_PRIVATE replacement of __srefill() and maybe
a little code to avoid unnecessary copy-on-write ops.
There are two problems: First, how to deal with unexpected file truncation
issues. Second, the extra syscalls involved: fstat(), mmap(), and
munmap() would have to be called quite often (fstat() to check for file
size changes). On the bright side, a relatively large map (e.g. 128K)
could be used. Maybe a sequential operation detect flag to revert the
behavior if there is excessive seeking/small-reads where syscall
overhead is killer verses the read() overhead.
-Matt
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811060401.UAA00767>