[sane-devel] SANE2 standard revisited: sane_get_select_fd

[Matto Marjanovic]

 >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.

I agree.

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".  
     Why not just have the frontend implement this once?  Frontends which
      never need non-blocking I/O (e.g. scanimage) don't need this at all
      anyway.

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

 c)  This mechanism of giving the frontend access to a file descriptor which
      is only 'valid' for use with select() is a hack (clever, but a hack).

 d)  The frontend can do a much more efficient job of 'unblocking' the
      sane_start()/sane_read() calls, since it knows where the data is
      going, and it knows what it might want to do while the calls block.
      It can use multithreading/shared-memory/semaphores, etc, etc.

(I'll try and dig up what I wrote about this before... I might have even
 more reasons.  It would probably be good to review the reponses, too. :)

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

Nope.  :)

 >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?

Yes.  Let the frontend take care of it.


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).

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

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.


-matt "simpler is better" m.