Karl Heinz Kremer wrote:
> Pipes are not the only IPC mechanism. Shared memory would probably be
> a lot faster. This of course may open up a totally different can of
> incompatibility worms.
I did some tests with pipes and shared memory between reader_process
and sane_read. With a AMD K6-2/400 you do not get any differences
in scanning speed. Large images (Transer rates over about 1MB/sec (if
I remember right) did make problems with both IPC mechanisms.
I did not continue to work on the shared memory routines
because the advantage is small compared to the problems you get with
it.
> Do you have any comparison data between a non-threaded and the threaded
> approach?
No. But threads make a lot of problems:
1) compatibility
2) no forks are allowed.
>
> What was the original idea behind implementing the second process in
> some of the backends?
The idea is to make the data flow between scanner and backend
independant from the data flow between backend and frontend.
But this also can be done by intelligent scsi command handling
and may be also by good usb command handling.
Bye
Oliver
-- Homepage: http://www.rauch-domain.de sane-umax: http://www.rauch-domain.de/sane-umax xsane: http://www.xsane.org E-Mail: mailto:Oliver.Rauch@rauch-domain.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 : Tue Jul 03 2001 - 05:49:26 PDT