kopia lustrzana https://gitlab.com/sane-project/website
103 wiersze
5.2 KiB
HTML
103 wiersze
5.2 KiB
HTML
<!-- received="Fri May 30 08:52:24 1997 MST" -->
|
|
<!-- sent="Fri, 30 May 1997 08:38:21 -0700" -->
|
|
<!-- name="David Mosberger-Tang" -->
|
|
<!-- email="davidm@azstarnet.com" -->
|
|
<!-- subject="Re: image buffering" -->
|
|
<!-- id="199705301538.IAA26859@panda.mosberger" -->
|
|
<!-- inreplyto="199705301305.JAA16982@nigel.redhat.com" -->
|
|
<title>sane-devel: Re: image buffering</title>
|
|
<h1>Re: image buffering</h1>
|
|
<b>David Mosberger-Tang</b> (<a href="mailto:davidm@azstarnet.com"><i>davidm@azstarnet.com</i></a>)<br>
|
|
<i>Fri, 30 May 1997 08:38:21 -0700</i>
|
|
<p>
|
|
<ul>
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#49">[ date ]</a><a href="index.html#49">[ thread ]</a><a href="subject.html#49">[ subject ]</a><a href="author.html#49">[ author ]</a>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0050.html">becka@sunserver1.rz.uni-duesseldorf.de: "Re: Logitech Support ?"</a>
|
|
<li> <b>Previous message:</b> <a href="0048.html">David Mosberger-Tang: "Re: mustek-probs: color, preview"</a>
|
|
<li> <b>In reply to:</b> <a href="0046.html">Mark Cornick: "Re: xcam/xscanimage hangs w/ SANE 0.57"</a>
|
|
<!-- nextthread="start" -->
|
|
<li> <b>Next in thread:</b> <a href="0047.html">David Mosberger-Tang: "Re: xcam/xscanimage hangs w/ SANE 0.57"</a>
|
|
<!-- reply="end" -->
|
|
</ul>
|
|
<!-- body="start" -->
|
|
<i>>>>>> On Fri, 30 May 1997 09:05:06 -0400, "Michael K. Johnson" <<a href="mailto:johnsonm@redhat.com">johnsonm@redhat.com</a>> said:</i><br>
|
|
<p>
|
|
Michael> Since we *do* have a reliable, portable method that works<br>
|
|
Michael> for finding the currently available disk space for the<br>
|
|
Michael> partition pertaining to any particular directory (see<br>
|
|
Michael> df...), and don't have a portable way to know how much<br>
|
|
Michael> memory is available, it seems to me that this is saner<br>
|
|
Michael> <groan>: if there's enough file space wherever the output<br>
|
|
Michael> file is:<br>
|
|
<p>
|
|
Michael> mmap output file<br>
|
|
Michael> if mmap failed,<br>
|
|
Michael> if there's enough space in (say) /var/tmp<br>
|
|
Michael> create a temp file there<br>
|
|
Michael> try to mmap the temp file (the previous mmap may have<br>
|
|
Michael> failed because the output file wasn't seekable)<br>
|
|
Michael> if mmap failed,<br>
|
|
Michael> write directly to temporary file<br>
|
|
Michael> if we still haven't figured out what to do<br>
|
|
Michael> malloc and hope for the best<br>
|
|
Michael> if malloc fails (unlikely) give an error message and exit.<br>
|
|
<p>
|
|
Michael> Since mmap is only going to fail on systems that don't<br>
|
|
Michael> support it (rare), or on pipes (which this deals with),<br>
|
|
Michael> this really resolves to mmap by choice, then malloc.<br>
|
|
<p>
|
|
I think I like a "malloc-or-temp-file approach better" for the<br>
|
|
following reasons:<br>
|
|
<p>
|
|
- in some cases, you won't know how much to mmap() since there<br>
|
|
is no realloc() equivalent of mmap() this could get ugly pretty<br>
|
|
fast (it's certainly doable, but is it worth the trouble?)<br>
|
|
<p>
|
|
- mmap() is in my experience the wrong thing when memory is short;<br>
|
|
while I can't quote any numbers, it seems like (at least on Linux),<br>
|
|
the VM system is quite agressive about keeping mmap'ped pages in<br>
|
|
RAM, which is bad for our purposes because we access the data in<br>
|
|
a strictly sequential fashion (which is the worst-case scenario for<br>
|
|
an LRU scheme when the working-set size exceeds the available RAM)<br>
|
|
<p>
|
|
- for scanning purposes, the performance difference between<br>
|
|
read()/write() and mmap() will be negligible since it's no<br>
|
|
problem to read/write large chunks of data per system call<br>
|
|
<p>
|
|
How about something like this:<br>
|
|
<p>
|
|
if output file is lseek'able<br>
|
|
tmp = output file<br>
|
|
else if we don't know the image size or if /var/tmp has enough space<br>
|
|
tmp = tmpfile ()<br>
|
|
else<br>
|
|
tmp = malloc ()<br>
|
|
<p>
|
|
Now, it would obviously be advantageous to make the accesses to "tmp"<br>
|
|
abstract so the same code can be used independent of whether "tmp"<br>
|
|
refers to a FILE* or to a malloc'ed area. This could be done through<br>
|
|
something like open_memstream(). But I think the way we use "tmp" is<br>
|
|
so simple that open_memstream() would be overkill---it might be both<br>
|
|
easier and more portable to simply cook our own abstract interface.<br>
|
|
All that's really needed is a seek and a write-byte operation.<br>
|
|
<p>
|
|
--david<br>
|
|
<p>
|
|
<pre>
|
|
--
|
|
Source code, list archive, and docs: <a href="http://www.azstarnet.com/~axplinux/sane/">http://www.azstarnet.com/~axplinux/sane/</a>
|
|
To unsubscribe: mail -s unsubscribe <a href="mailto:sane-devel-request@listserv.azstarnet.com">sane-devel-request@listserv.azstarnet.com</a>
|
|
</pre>
|
|
<!-- body="end" -->
|
|
<p>
|
|
<ul>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0050.html">becka@sunserver1.rz.uni-duesseldorf.de: "Re: Logitech Support ?"</a>
|
|
<li> <b>Previous message:</b> <a href="0048.html">David Mosberger-Tang: "Re: mustek-probs: color, preview"</a>
|
|
<li> <b>In reply to:</b> <a href="0046.html">Mark Cornick: "Re: xcam/xscanimage hangs w/ SANE 0.57"</a>
|
|
<!-- nextthread="start" -->
|
|
<li> <b>Next in thread:</b> <a href="0047.html">David Mosberger-Tang: "Re: xcam/xscanimage hangs w/ SANE 0.57"</a>
|
|
<!-- reply="end" -->
|
|
</ul>
|