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