[sane-devel] SANE2 standard revisited: sane_get_select_fd

[Henning Meier-Geinitz]

Hi,

On Mon, Dec 09, 2002 at 02:14:17PM -0500, Matto Marjanovic wrote:
> The select mechanism should be removed entirely.  I'm not a fan of the 
>  non-blocking I/O either (see below).
> 
> Here are some reasons:
> 
>  a)  Currently, every backend which has non-blocking I/O and a selectable
>       fd implements its own version of "fork a reader process".  

If it does this just to provide a select_fd or non-blocking i/o that's
not very intelligent :-)

But I don't think that's the reason. The crappy old SCSI adapters and
some new low-RAM USB scanners need to get the image data buffers
really fast. There can't be a long delay between getting back a filled
buffer and submitting a new one because the scan head will stop
otherwise. It's not that the transfer rate is that high, the delay
between buffers mustn't bee to long.

With SCSI, you can work around this because you can do submit the
buffer and do other stuff meanwhile. With USB you can't. At least not
with the current implementation of libusb. So you can't just call
usb_bulk_read(), do whatever you need with the data, wait for
sane_read, and call usb_bulk_read() again when sane_read has gotten
all the data. With my scanners this would mean backtracking after
every line of data.

So the reader_process will stay for some backends. I'm currently
buffering 10 lines in the reader process and they are needed if I e.g.
move a window in X.

>  b)  Reader processes created by the backend require the image data to
>       make an extra trip through a pipe.  That's inefficient.

True. But shared memory can be used when available.

> 
>  >So the provoking question is: Do we need sane_get_select_fd at all?
> 
> Nope.  :)

Still true in my opinion. But I know mostly the backend side so maybe
a frontend developer has different opinions.

> And, here is why I don't like sane_set_io_mode() either:
> 
>  >I don't see problems with sane_set_io_mode. That one doen't seem to
>  >cause trouble.
> 
> It doesn't really hurt, but it doesn't really help either:
> 
> A backend shouldn't have to bother with creating reader processes, etc,
>  i.e. it should not _go out of its way_ to implement non-blocking I/O.
>  Thus, if the underlying device it controls (say, a Linux SCSI device)
>  only implement blocking I/O, then the backend has no choice but to do
>  blocking I/O (since the backend will block when it talks to the device).

Implementing non-blocking i/o in the backend withou the lowerlevel
functi ons supporting it doesn't make much sense, that's true.

> Thus, a frontend cannot expect a backend to implement non-blocking I/O.

It doesn't. The frontends work without it, too :-)

> Thus, if a frontend wants to avoid blocking, it must implement some
>  multiprocess/multithread scheme to avoid potential blocking.
> 
> Thus, such a frontend does not need to use non-blocking I/O, even if it
>  is available from the backend!
> 
> So, why bother?  Remove sane_set_io_mode() and eliminate more confusion.

No objection from me.

And removing won't cause incompatibilities with older backends, because
the old functions just won't be called.

Bye,
  Henning