Re: What's the status of sanei-thread?

From: Oliver Rauch (oliver.rauch@rauch-domain.de)
Date: Mon Jul 02 2001 - 14:16:24 PDT

  • Next message: Yuri Dario: "Re: What's the status of sanei-thread?"

    Is there no driver based command queueing for USB?
    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
    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.

    So if there is an other way to handle this we should
    take a closer look at it.

    Bye
    Oliver

    Karl Heinz Kremer wrote:
    >
    > This does not work for USB. For consumer scanners USB is becomming
    > more and more important, also the cheaper a scanner is, the more
    > has to be done in software. Running two processes, one to get the
    > data and the other one to process the data seems to be the ideal
    > solution to improve the throughput.
    >
    > So I'll pass on this one.
    >
    > Karl Heinz
    >
    > Oliver Rauch <oliver.rauch@rauch-domain.de> said:
    >
    > > Karl Heinz Kremer wrote:
    > > >
    > > > I am in the process of adding a reader thread to the EPSON backend.
    > > > I noticed that the library module sanei-thread does some of the
    > > > work that's necessary to create a reader process in a somehow
    > > > cross-platform way (at least for any OS that supports fork() and
    > > > OS/2). I also noticed that no backend is using these functions.
    > > > What's the status of this module?
    > >
    > > I thought about the reader_process thing and I think there is a
    > > chance that we do not need it:
    > > most (all?) scsi controller drivers (and some controllers in hardware)
    > > do support scsi command queueing. When the queueing is done with
    > > 2 scsi read commands and 2 scsi buffers who are handled a bit smart
    > > in sane_read() we (may be) do not need the reader_process
    > > and may be get better performence because we do not need the
    > > pipe between the reader_process and the main process.
    > >
    > > May be you like to try this idea.
    > >
    > > 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
    > >
    >
    > -- 

    -- 
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 : Mon Jul 02 2001 - 14:10:11 PDT