Re: snapscan

From: Christian Nassau (
Date: Mon Jan 15 2001 - 04:20:34 PST

  • Next message: Mark Stewart: "Re: Umax 600s/Adaptec 2906 trouble"

    Hello Henning,

    thanks for your message. But of course I still disagree. ;-)

    You wrote
    > The standard defines the meaning of blocking/non-blocking mode in
    > chapter 4.3.10 (sane_read). Blocking/non-blocking describes the
    > behaviour of sane_read in the case that no data is available.

    and that brings us to the heart of the matter/problem: The meaning
    of "having data avilable" is not made precise in the standard.
    This notion cannot (and should not) refer to any "physical" entity,
    like an internal buffer in the backend (may not exist), an
    internal buffer in the scanner (may not exist neither), and so on.

    The standard comes close to actualy define the meaning of "available"
    in the following line (taken from the get_select_fd specification):

      ...image data is available, (i.e., when a call to sane_read() will
      return at least one byte of data).

    If we read "i.e." as "equal by definition" we arrive at the
    tautological definition of available: a backend had data available
    iff a call to sane_read transferred at least one byte.

    But actually I don't want to turn this into a lawyer's kind of
    discussion, so let me state my case more plainly and bluntly,
    like this:


      In blocking mode a backend should be allowed to transfer
      zero bytes and return SANE_STATUS_GOOD (i.e. same behaviour
      as currently admitted in nonblocking mode)

    To prove this, I'll show three things:

      A) desireable behaviour made possible by this modification
      B) a (potential) real life example
      C) a remark on the compatibility with existing frontends

    (We always deal with blocking mode in the following.)

    A) A backend might know that data will not arrive in the immediate
       future. If there is nothing useful to be done, the backend
       should be allowed to give control back to the frontend, for
       example to allow user interaction.

       (Currently, it is forced to explicitly wait (= waste time) in this

    B) Assume the backend is reading image data from a remote host over
       an TCP/IP connection. (For example, we could be scanning the
       Mona Lisa through the Louvre's internet server.) In this case
       there is no access to the scanner that could --- in any substantial
       way --- be called blocking. So for this device non-blocking mode
       is the only one that is "naturally" supported, and blocking mode
       would have to faked (= simulated), by deliberately wasting time.

    C) If a frontend depends on sane_read's old (= current) behaviour
       it can simulate it like this:

          do {
             call sane_read
          } while (no error && no bytes transferred)

    So I think this actually proves that the standard should be changed.

    Of course I don't know if I'm right, and actually hope for counter
    opinions. However, any counter argument should do one of the

      Show that I'm wrong about points A, B, or C.


      Point out undesirable behaviour permitted by the new specification.
      (But make sure this behaviour is not currently allowed!)


    Source code, list archive, and docs:
    To unsubscribe: echo unsubscribe sane-devel | mail

    This archive was generated by hypermail 2b29 : Mon Jan 15 2001 - 04:22:16 PST