[sane-devel] Proposal: SANE standard additions/fixes

[Henning Meier-Geinitz]

Hi,

On Sun, Oct 06, 2002 at 01:01:52PM -0400, Matto Marjanovic wrote:
>  >2) Concerning sane_get_select_fd: It's not that easy to implement the
>  >   select fd correctly in frontends and backends. For frontends the
>  >   problem is, that not only the readable status has to be cheked but
>  >   also if the fd was closed. E.g. using a gdk_input will not work
>  >   because it won't detect the closing of the file descriptor by the
>  >   backend and waits forever.
>  >   
>  >   So if you use select you have to check the return value of select
>  >   if the fd was closed (that means EOF in the next call to SANE_READ)
>  >   and so you can call sane_cancel. If no error occured, check if the
>  >   fd is readable. If yes, run sane_read, otherwise wait.
>  >   
>  >   Maybe we can add a "frontend implementation note" for that one.
>  >   I don't know how to write this exactly, maybe Oliver?
> 
> Well, I was the guy who thought it might be a good idea to get rid of this
>  mode of operation altogether, so I'm not the best one to comment.  (Feel
>  free to skip ahead; somehow it turned into thoughts on the semantics of
>  sane_cancel(), until (e) and (f)....)

I'm also not sure if that mode is really necessary but changing that
is for SANE2. Maybe it makes sense for networking/saned?

> The standard does seem to be unclear on what happens when sane_cancel()
>  is called:
> 
>  a) If you are in the middle of another sane call, and sane_cancel() is
>     called (via a signal handler), the spec is clear:  the scan is officially
>     cancelled once the current call returns with SANE_CANCELLED.

True.

>  b) If you are *not* in the middle of another sane call, what happens?
>     If I call sane_cancel() in between calls to sane_read(), is the scan
>     cancelled immediately upon returning from sane_cancel(), or are you
>     allowed or required to call sane_read() once more so that you get a
>     return value of SANE_CANCELLED?