# Re: fork or pthread for async I/O?

From: abel deuring (a.deuring@satzbau-gmbh.de)
Date: Fri Feb 04 2000 - 04:06:25 PST

- Next message: Harald Kirsch: "lunatic listserver"
  - Previous message: abel deuring: "Re: SG_BIG_BUFF setting in Problems incorrect"
  - In reply to: Wolfgang Rapp: "Re: fork or pthread for async I/O?"
  - Next in thread: Wolfgang Rapp: "Re: fork or pthread for async I/O?"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  Wolfgang Rapp wrote:
  >
  > abel deuring wrote:
  >
  > >
  > >
  > > I agree, that the small time window for sending a "read" command after
  > > finishing the previous read and not having the scan head stop is indeed
  > > the main cause for scan heads stops -
  >
  > I think this is exactly the main point and I am able to compare .
  >
  > Before I did the Unixware 2 port of sane I wrote a driver for Microtek
  > Scanmaker.
  > In this solution the whole scanning loop was inside the driver and the
  > application
  > set up one read command for the whole scan. This driver runs mutch more
  > faster
  > than the sane solution with minimum head stops. It only stops if the
  > application must
  > swap the huge allocated memory on the same SCSI controller. Mutch more
  > better if the
  > swap is on a IDE disk or seperate controller.
  >
  > If I recogmized it well , all backends send a lot of times the same
  > SCSI-Command block with
  > following read system call. Is it right that only the last Command differs
  > in most cases?
  > So the only solution could be that the backends tell sanei_scsi how
  > often a certain
  > SCSI-Command should be executed and sanei_scsi decides what to do on the
  > different
  > platforms and alloc the memory. It's clear that this needs special sane
  > drivers for every platform
  > if the scan should be as fast as possible but don't prevent using the
  > current method if no special
  > driver is available In my opinion this is the only way to speed up scans
  > and avoid head stops.
  > What could happen that we can't cancel a scan so easy because we only may
  > interrupt system calls
  > by signals. But we can send a SIGALRM to do this.

  I think, there already exists a mechanism in sanei_scsi.c, the function
  pair sanei_scsi_req_enter (send a SCSI command to the scanner) /
  sanei_scsi_req_wait (wait for the results of the command).
  Unfortunately, they are at present only for Linux implemented in "real"
  way; for the other OS, sanei_scsi_req_enter simply calls sanei_scsi_cmd,
  and sanei_scsi_req_wait is empty.

  But there are some scanners, for which the queueing does not seem to
  help: I pplayed a little bit with an old Mustek scanner (sorry, I don't
  know the exact type; it was sold in Germany under the brand name
  "Network", and the inquiry command did not tell me anything I could
  recognise as a model specification...) The Mustek backend already
  supports queueing, therefore I hoped that my patches to the Linux
  queueing might help to avoid some scan head stops, but I had no luck. I
  guess that the scanners's firmware is a little bit stupid, and stops
  after every "read scan data" command. With such a scanner, the only way
  to improve the scan speed is to use large buffers.

  Abel

      --
      Source code, list archive, and docs: http://www.mostang.com/sane/
      To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

  - Next message: Harald Kirsch: "lunatic listserver"
  - Previous message: abel deuring: "Re: SG_BIG_BUFF setting in Problems incorrect"
  - In reply to: Wolfgang Rapp: "Re: fork or pthread for async I/O?"
  - Next in thread: Wolfgang Rapp: "Re: fork or pthread for async I/O?"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Fri Feb 04 2000 - 03:56:56 PST