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

[m. allan noah]

hopefully this comes thru- my sane devel mails seem to disappear...

On Mon, 30 Oct 2006 astrand at cendio.se wrote:

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

ajax is beside the point. lets just say that there are apps where 
non-blocking is not required, and apps where it is. and in every case i 
can think of, it is the FRONTEND that has the reason for it to be 
non-blocking.

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

perhaps we have different values for 'quite a bit'. you obviously are a 
more accomplished programmer than me, so maybe not scared by a few lines 
of C :)

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

no. 'A backend may elect not to support non-blocking I/O mode' and 'A 
backend may elect not to support this operation'. they are _optional_, and 
any application that 'requires' these in a backend is broken.

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

correct, but _only_ if he needs it for his frontend. no-one needs to 
thread/fork if the frontend does not care to.

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

my preferred solution, but i do not speak for the other devels.

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

in general, the backend is going to have to fork/thread to give you your 
select_fd. i feel that the management of such OS-specific libs, creation 
of children, dealing with signals, etc. is in the frontend.

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

correct. i have chosen not to complicate the backend for what i perceive 
as a limited, optional benefit.

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

i would say at this point, that the only way you would ever see that kind 
of change would be as a part of the SANE2 standard. there are just too 
many existing backends that would have to be changed.

the better solution, imho, is the one taken by e.g. XSANE. if your 
frontend cares about non-blocking mode because its a gui or whatever, 
then let it deal with the issue. this is pretty much standard fare for 
other libs for dns resolves, http/ftp transfers, etc. existing SANE-1 
backends can drop the code which provides these options, and the ABI/API 
does not change. SANE2 can remove the function calls, or leave them such 
that old frontends can be easily ported.

allan

-- 
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera