[sane-devel] SANE2 standard revisited: sane_get_select_fd

Henning Meier-Geinitz henning@meier-geinitz.de
Fri, 6 Dec 2002 19:55:31 +0100


Hi,

On Thu, Dec 05, 2002 at 06:09:57PM +0100, Henning Meier-Geinitz wrote:
> http://www.meier-geinitz.de/sane/sane2/

| 4.3.13 sane_get_select_fd
http://www.meier-geinitz.de/sane/sane2/0.07/doc012.html#s4.3.13

This function has caused a lot of trouble and misunderstandings. Or to
be more exact: not the function itsself but the select_fd and its
handling.

The frontend must not only check if the select_fd is readable and call
sane_read in this case (that's easy) but also if it was closed. And
it's not the "other side of the pipe" that's closed, it the fd itsself.
I haven't checked recently but some time ago the frontends didn't
implement this correctly. E.g. it doesn't work with gdk_input_add
because the handler function won't be called when the select_fd is
closed.

So the provoking question is: Do we need sane_get_select_fd at all?

The standard says:

| Since many input devices are very slow, support for this operation is
| strongly encouraged as it permits an application to do other work
| while image acquisition is in progress. 

But isn't it easier for the application to do its "other work" after a
call to sane_read returned 0 bytes ("try again later")? Or even to use
a reader process (forked or threaded) to call sane_read?

My impression is that the problem with windows not beeing updated
occurs most often in sane_start, not sane_read because some
long-running operations like calibration are done in sane_start.

Do we need it?

I don't see problems with sane_set_io_mode. That one doen't seem to
cause trouble.

Bye,
  Henning