Mathias> swapspace) and I think not many people on Linux have.
Mathias> David mentioned that a temporary file wouldn`t be a nice
Mathias> solution. Here is my question: Why not ? Shouldn't it be
Mathias> possible to write three temporary files for the red, green
Mathias> and blue frame (of course not as image but the red bytes in
Mathias> a line...) so that each will consume 1/3 of the entire
Mathias> image in space? After the last pass the picture can be put
Mathias> together from those three files and send to stdout or file.
DM> It's certainly possible. Michael suggested using mmap'ing to
DM> provide backing store in the filesystem instead of the
DM> swap-space. Of the two solutions, I think mmap is technically
DM> preferable when there is plenty memory available. On the other
DM> hand, mmap is still quite a portability nightmare, so using
DM> regular files might still be better, overall.
Gord> Why not write to a single file (every third byte, for
Gord> example), and on each other pass, read a bufferful from the
Gord> file, add in the bytes from the scanner, and write the
Gord> bufferful back to the file. This would be a close alternative
Gord> to mmap (which you could still use on systems that have it
Gord> implemented correctly).
Gord> In combination with the ``reserve space for the header'' idea
Gord> I mentioned before, this would never use more space than the
Gord> resulting image file.
True as long as the output is a real file. With a pipe, seeking is
not possible and there is no way to avoid using twice the minimum
amount of buffer space. But, of course, one could argue that if i use
a pipe on a 3-pass or hand-scanner scanner, it deserves to die... ;-)
DM> To me, it seems like we should use memory/swap-space when it
DM> looks like the image might fit in the available
DM> memory/swap-space and use temporary files otherwise. E.g., on
DM> Linux, we could base this decision on MemTotal: as reported in
DM> /proc/meminfo.
Gord> I dislike this sort of decision making... by Murphy's law, it
Gord> will make bad decisions in at least a few circumstances.
In general, I do too.
Gord> By using a constant in-memory buffer, the total space requirement
Gord> will never exceed imagesize + reserved_header + buffersize.
Gord> Otherwise, we're talking at least 2 * imagesize.
I don't see how to avoid the 2*imagesize worse-case with pipes. Since
we don't have any problems in the other case, the question is how
important do we think this case is. To me it seems it would be quite
reasonable to say "look, if you use pipes, be prepared that you'll
need more temp space than if you use a regular file".
Gord> Heck, I'll even help with implementation if that's the extra
Gord> push that's needed to convince any skeptics. :)
That would work for me! ;-)
Seriously though: I now think that using a temporary file is not such
a bad idea. I think pipes could be supported easily as well: if a
dummy lseek() fails, then a tmpfile(3) could be used as a temporary
buffer.
--david
-- Source code, list archive, and docs: http://www.azstarnet.com/~axplinux/sane/ To unsubscribe: mail -s unsubscribe sane-devel-request@listserv.azstarnet.com