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

From: Wolfgang Rapp (wolfgang@rapp-informatik.de)
Date: Thu Feb 03 2000 - 15:20:21 PST

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

  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.

  Greetings Wolfgang

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

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

  This archive was generated by hypermail 2b29 : Thu Feb 03 2000 - 13:11:27 PST