[sane-devel] Neither get_select_fd() nor non-blocking

[astrand at cendio.se]

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


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

2) Application developers needs to support backends which cannot do 
   non-blocking or get_select_fd, and must therefore use threading/forking 
   themself. 

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 
http://www.sane-project.org/html/doc000.html:

"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 
solution:

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. 


Regards, 
-- 
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.se
Teknikringen 3
583 30 Linköping	Phone: +46-13-21 46 00