Re: image buffering

Michael K. Johnson (johnsonm@redhat.com)
Fri, 30 May 1997 09:05:06 -0400

David Mosberger-Tang writes:
>>>>>> On 29 May 1997 20:47:38 -0600, Gordon Matzigkeit <gord@m-tech.ab.ca> said:
> Gord> Sane defaults, to me, would be trying to malloc the whole
> Gord> thing, then if that fails, mmapping, and if that fails,
> Gord> writing to a temp file.
>
>Caveat: mmap() will not fail on systems with lazy swap-space
>allocation (such as Linux). Somebody will get a SIGSEGV when running
>out of space, but it's not necessarily the application that used "too
>much" memory.

I assume you meant malloc(), not mmap(). That's true for our purposes,
but not generally. malloc() will not *necessarily* fail -- but it will
fail in very extreme cases with recent Linux versions.

Since we *do* have a reliable, portable method that works for finding
the currently available disk space for the partition pertaining to any
particular directory (see df...), and don't have a portable way to know
how much memory is available, it seems to me that this is saner <groan>:
if there's enough file space wherever the output file is:
mmap output file
if mmap failed,
if there's enough space in (say) /var/tmp
create a temp file there
try to mmap the temp file (the previous mmap may have
failed because the output file wasn't seekable)
if mmap failed,
write directly to temporary file
if we still haven't figured out what to do
malloc and hope for the best
if malloc fails (unlikely) give an error message and exit.
Since mmap is only going to fail on systems that don't support it (rare),
or on pipes (which this deals with), this really resolves to mmap by choice,
then malloc.

And this can be changed by a preferences setting if there's a reason to
do so, though I don't see any such reason.

Sorry to keep posting stuff like this without having a ghost of a chance
of implementing it in the near future. :-(

michaelkjohnson

"Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?"

--
Source code, list archive, and docs: http://www.azstarnet.com/~axplinux/sane/
To unsubscribe: mail -s unsubscribe sane-devel-request@listserv.azstarnet.com