Re: fork or pthread for async I/O?

From: Douglas Gilbert (dgilbert@interlog.com)
Date: Wed Feb 02 2000 - 20:21:39 PST

  • Next message: Peter J Jones: "Re: xscanimage and Gimp Menu Location"

    Oliver Rauch wrote:
    >
    > msitkows@au1.ibm.com wrote:
    >
    > >
    > > Add to that, the fact that different versions of Unix (like AIX or Solaris)
    > > use slightly different implementations of pthreads with each release, and
    > > my advice would be, forget it. I think portability is more important, for a
    > > public software package.
    > >
    >
    > Hi,
    >
    > I think the same.

    Most scsi scanners do not support disconnect or tagged queuing
    so you are not going to get much benefit from async io. Abel
    Deuring has done some work in this area and did get some
    timing improvements on Linux. I think scsi commands were
    probably queued up at the HBA and thus got out to the
    scanner quicker after it finished the previous command
    (compared with having to go up through the scsi layers,
    out to the app and back down again). Abel used non blocking
    techniques rather than POSIX threads, I think. [I have used
    POSIX threads to do async IO on high end disks with good
    results (compared with the standard dd command).]

    There seems to be a non-linear effect with scanners. You have
    a time window to get the next "read" out to the device after
    the previous one has finished. If the window is missed the
    scan stops, the mechanism backs up a little and recommences.
    A small change in the speed the next command gets out to the
    scanner can mean the difference between a slow, jerky scan
    and one continuous pass.

    Doug Gilbert

    --
    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 : Wed Feb 02 2000 - 20:33:45 PST