Re: SANE standard / get_select_fd / sane_read

From: Christian Nassau (nassau@math.uni-frankfurt.de)
Date: Mon Jan 15 2001 - 03:48:02 PST

  • Next message: Christian Nassau: "Re: snapscan"

    Hello Oliver,

    thanks for your remarks on the subject. I've come to accept
    that a frontend may request any number of bytes. However,
    I would still insist that deadlocks (in non-blocking mode)
    are inherent in the current standard.

    Your reply to this was
     
    > Wrong.
    > Non Blocking mode means that the backend may return with 0 bytes
    > transfered (because it has no data in the moment and it returns
    > to give the frontend the chance to react to user action, refresh display
    > etc.)

    I think this is inconsistent. Either say

    > Right.
    > Non Blocking mode means that the backend may return with 0 bytes
    > transfered (plus some comments that I may ignore, since they only
    > refelct the presumed intention of the specs)

    or

    > Wrong.
    > In non blocking mode the backend may only return with 0 bytes
    > transfered if it has no data available at the moment.

    In my reading this last version would be either wrong or tautological,
    (but essentially (or substantially?) wrong.)

    Our difference of reading could be this: the notion of "having
    data available" is nowhere made precise in the SANE specification,
    so I take it to be essentially tautological: a backend had data
    available (by definition) if a call to sane_read transferred at
    least one byte.

    I still think the sane_read specification ought to be changed.
    For this, see the reply to Henning Meier-Geinitz' message,
    which I'll write next,

    Christian

    --
    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 : Mon Jan 15 2001 - 03:51:12 PST