Matto Marjanovic wrote:
> I just wanted to throw in my two cents on this, because I haven't heard
> something that I expected to hear in the whole thread on this issue....
>
> It's been my understanding that, originally, all the forking around in
> the backends was in order to implement asynchronous I/O, and the intent
> of asynchronous I/O (and sane_set_io_mode()) was not to tune the scanner
> speed, but to improve GUI response. Under async I/O, the GUI/frontend
> would not block while waiting for the backend to deliver a full buffer
> of data.
Async I/O is one reason, the other reason is that you can read any number of bytes
from the pipe (what you can not do if you read the data directly from the scanner).
But both can be done without a fork if the frontend calls sane_read with a high frequency.
If it does not, the solution with the pipe does not help a lot because the reader process
can only read one more buffer from the scanner. That can be done with the second
(or double size) scsi buffer in the backend without a seperate reader_process.
So I think I could be faster to throw away the fork and the pipe.
The fork only makes sense when the pipe/file buffer is at least as large as the scsi buffer.
I heard that it could be possible to increase the size of the pipe buffer by a fcntl but did not
find anything about that. So the fork only makes sens when we write the data to a file.
Bye
Oliver
-- Homepage: http://www.wolfsburg.de/~rauch sane-umax: http://www.wolfsburg.de/~rauch/sane/sane-umax.html xsane: http://www.wolfsburg.de/~rauch/sane/sane-xsane.html E-Mail: mailto:Oliver.Rauch@Wolfsburg.DE-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Mon Feb 21 2000 - 08:25:26 PST