On Mon, Jul 02, 2001 at 11:16:24PM +0200, Oliver Rauch wrote:
> Is there no driver based command queueing for USB?
Not for the scanner driver, or at least not without modifications
to the scanner driver.
> Also if there is no queueing, you can do:
>
> 1) read on buffer1
> 2) initiate read of buffer2
> 3) sane_read can get buffer1, when buffer1
> is empty wait until buffer2 is read (should already
> be done) and initiate read of buffer1 again.
> etc.
>
> There are two problems with the reader_process
> 1) fork does not work on all systems
My plan actually was to make this a compile time option so that the
original non-read-process version would still be available.
> 2) the pipe as IPC is not very good because the
> buffer is very small (about 4KB on most systems).
> This can(unnecessaryly) slow down scanning on slow
> systems.
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.
Do you have any comparison data between a non-threaded and the threaded
approach?
What was the original idea behind implementing the second process in
some of the backends?
Karl Heinz
-- Karl Heinz Kremer khk@khk.net PGP Key at http://www.freecolormanagement.com/download/khk.asc EPSON Sane Backend: http://www.freecolormanagement.com
-- 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 Jul 02 2001 - 18:30:38 PDT