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"

    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
    



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