Hi, On Thu, Dec 05, 2002 at 06:09:57PM +0100, Henning Meier-Geinitz wrote: > http://www.meier-geinitz.de/sane/sane2/
| 4.3.13 sane_get_select_fd http://www.meier-geinitz.de/sane/sane2/0.07/doc012.html#s4.3.13 This function has caused a lot of trouble and misunderstandings. Or to be more exact: not the function itsself but the select_fd and its handling. The frontend must not only check if the select_fd is readable and call sane_read in this case (that's easy) but also if it was closed. And it's not the "other side of the pipe" that's closed, it the fd itsself. I haven't checked recently but some time ago the frontends didn't implement this correctly. E.g. it doesn't work with gdk_input_add because the handler function won't be called when the select_fd is closed. So the provoking question is: Do we need sane_get_select_fd at all? The standard says: | Since many input devices are very slow, support for this operation is | strongly encouraged as it permits an application to do other work | while image acquisition is in progress. But isn't it easier for the application to do its "other work" after a call to sane_read returned 0 bytes ("try again later")? Or even to use a reader process (forked or threaded) to call sane_read? My impression is that the problem with windows not beeing updated occurs most often in sane_start, not sane_read because some long-running operations like calibration are done in sane_start. Do we need it? I don't see problems with sane_set_io_mode. That one doen't seem to cause trouble. Bye, Henning
