[sane-devel] Neither get_select_fd() nor non-blocking
astrand at cendio.se
astrand at cendio.se
Mon Oct 30 15:23:13 UTC 2006
> there are plenty of front-ends for which non-blocking mode is not required
> (think command line, or cgi script, etc). all of my front-ends work this way.
You might need non-blocking with command line or cgi scripts as well.
Nowadays, users expects "AJAX-typ" pages, that can load incrementally. The
old style "read everything, write everything" is not fun, not even with
> if each backend (there are 68+ of them) has both a blocking and a non-blocking
> mode, that is quite a bit of code.
Is it, really? I haven't written a backend myself, but from the source,
it's not obvious that "quite a bit of code" code be removed by removing
the non-blocking support.
> it is also significantly more difficult to debug the backend when it is
> multi-threaded. given that many of our backends are rarely touched or
> are maintained by someone other than the original author, it makes sense
> to keep them simple.
I agree, I want to make it simple, both for the backend and application
developers. The problem with the current situation is:
1) Backend writers "needs" to support non-blocking and get_select_fd,
since the documentation says they should, and some applications might
2) Application developers needs to support backends which cannot do
non-blocking or get_select_fd, and must therefore use threading/forking
This seems like a lose-lose situation: Both the backend and frontend
developers needs to handle all three cases. Well, the frontend developers
could skip to try non-blocking and get_select_fd and *always* thread/fork
themselves. But that would mean that the non-blocking/get_select_fd code
in the backends are useless. So one idea is to simply make non-blocking
sane_read and get_select_fd deprecated, and eventually remove them...
> besides, its easier for app developer (who likely has multi-threading in his
> app already for other purposes) to decide that he needs it, and deal with the
> threading himself.
Personally, I think the select loop model is superior, but since not all
backends supports get_select_fd, an otherwise select based application
might be forced to start to fork/thread. Not pretty.
> the fujitsu backend no longer has threading for this reason.
That means that you are not following the recommendations at
"support for this operation is strongly encouraged"
I'm not really sure of what needs to be done, but again, I believe the
current situation is non-optimal. Right know, I tend to favourize this
1) Deprecate sane_set_io_mode() (and thus non-blocking sane_read()). It
doesn't give the frontend developer anything that sane_get_select_fd()
+ select() doesn't give.
2) Make sane_get_select_fd() mandatory on UNIX.
The only "problem" with this solution is that the select based model
cannot be used on Windows, but few people wants this anyway, they are
using threads instead.
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.se
583 30 Linköping Phone: +46-13-21 46 00
More information about the sane-devel