Hi,
On Mon, Jan 15, 2001 at 01:20:34PM +0100, Christian Nassau wrote:
> and that brings us to the heart of the matter/problem: The meaning
> of "having data avilable" is not made precise in the standard.
Even if you are right about this it doesn't really matter. The
difference between blocking and non blocking is that just length can
be 0 in the latter and it can't be in the first case. It doesn't
really matter why the backend wants to return 0 (no data at all,
waiting for a larger amount of data or whatever).
> THE SPECIFICATION of sane_read HAS TO BE CHANGED:
Just to be sure: The SANE standard 1.x won't be changed in any way
that renders it incompatible with earlier 1.x standards. No way. If we
discuss about changes (in general) these are changes for 2.x.
> 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)
The name "blocking" / "non blocking" probbably comes from Unix. So it's
just defined this way. So if a function returns immediately even if no
data will be transmitted it is non-blocking.
> (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
> case.)
It isn't. If the frontend wants to regain control if nothing can be
done during sane_read it will use non-blocking mode. This is done e.g.
by xscanimage (updating windows etc). scanimage only uses blocking
mode. As it's non-interactive that's ok. There isn't anything it could
do when it regains controll, it would just do another sane_read.
> 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.
As I said above if blocking mode is used by the frontend that's
intentional. Just "wait" in the backend (do a select or whatever).
Your example isn't that special. When I start a scan with the Mustek
backend, it's just the same. There won't be any data to transmit for
some time. In none-blocking mode sane_read just returns. In blocking
mode the baceknd waits until at least one byte arrived (it will wait
for a whole block of data but this doesn't matter). No problem here.
If the frontend doesn't like the latter behaviour, it can use
non-blocking mode.
> 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)
That's the job of the backend.
> So I think this actually proves that the standard should be changed.
Sorry, I don't see any reason at all. It justs work for all the
backends and frontends. You want to remove blocking mode because you
think waiting is nonsense. But that's the whole idea of blocking mode:
"Give me the data, there is nothing to do for me in the mean time".
Ciao,
Henning
-- 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 - 12:04:29 PST