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

[astrand at cendio.se]

On Mon, 30 Oct 2006, m. allan noah wrote:

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

Yes, it is the frontend that has the need. The question is how much 
backends should provide. In other words: Who will need to do the hard 
work: The backend or the frontend developer? I'm not surprised that 
backend developers wants to implement as little of the API as possible :)


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

True, you have a point here. 


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

I think that this solution is at least better than doing nothing at all. 
I'm positive. 


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

You have a point. OTOH, sanei does provide this infrastructure. 


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

After looking through about 30% of the backends, I believe you are 
correct. Most backends does not support get_select_fd(). 


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

For DNS resolves you have ADNS. Many HTTP libs also provides non-blocking 
support. 

But, you have a point, I agree. libusb doesn't currenly provide an 
asynchronous interface either. 

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