> > 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 From an...@pfeiffer.edu Mon Oct 30 17:16:49 2006 From: an...@pfeiffer.edu (m. allan noah) Date: Mon Oct 30 17:17:43 2006 Subject: [sane-devel] Neither get_select_fd() nor non-blocking In-Reply-To: <pine.lnx.4.64.0610301622460....@maggie.lkpg.cendio.se> References: <pine.lnx.4.64.0610301622460....@maggie.lkpg.cendio.se> Message-ID: <pine.lnx.4.61.0610301041010.16...@limos.pfeiffer.edu> hopefully this comes thru- my sane devel mails seem to disappear... On Mon, 30 Oct 2006 astr...@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
