Hi, On Sun, Oct 06, 2002 at 01:01:52PM -0400, Matto Marjanovic wrote: > >2) Concerning sane_get_select_fd: It's not that easy to implement the > > select fd correctly in frontends and backends. For frontends the > > problem is, that not only the readable status has to be cheked but > > also if the fd was closed. E.g. using a gdk_input will not work > > because it won't detect the closing of the file descriptor by the > > backend and waits forever. > > > > So if you use select you have to check the return value of select > > if the fd was closed (that means EOF in the next call to SANE_READ) > > and so you can call sane_cancel. If no error occured, check if the > > fd is readable. If yes, run sane_read, otherwise wait. > > > > Maybe we can add a "frontend implementation note" for that one. > > I don't know how to write this exactly, maybe Oliver? > > Well, I was the guy who thought it might be a good idea to get rid of this > mode of operation altogether, so I'm not the best one to comment. (Feel > free to skip ahead; somehow it turned into thoughts on the semantics of > sane_cancel(), until (e) and (f)....)
I'm also not sure if that mode is really necessary but changing that is for SANE2. Maybe it makes sense for networking/saned? > The standard does seem to be unclear on what happens when sane_cancel() > is called: > > a) If you are in the middle of another sane call, and sane_cancel() is > called (via a signal handler), the spec is clear: the scan is officially > cancelled once the current call returns with SANE_CANCELLED. True. > b) If you are *not* in the middle of another sane call, what happens? > If I call sane_cancel() in between calls to sane_read(), is the scan > cancelled immediately upon returning from sane_cancel(), or are you > allowed or required to call sane_read() once more so that you get a > return value of SANE_CANCELLED?
