Hi, On 2006-04-25 15:07, Wittawat Yamwong wrote: > Should/must/may a frontend call sane_read after sane_cancel?
I think it may but it doesn't need to. I can't find an explicit statement in the standard that it's forbidden to do so. In fact, there is even a status code for sane_read for this case. But it's also not necessary (and not really logical) to call sane_read after sane_cancel(). > Case II: The frontend has read a block of image data from a backend and it is > writing the data to a file but a IO error occurs. > The frontend probably calls > sane_cancel. What will/must the frontend do next? Will it call sane_read > until an error or EOF occurs? It should do nothing (or call sane_close, sane_exit). > This is important to my backend (pixma). It would be much more complex if > frontends are not required to call sane_read after sane_cancel because I have > to check whether sane_cancel was called synchronously or asynchronously. If > it's called synchronously (case II), an outstanding scan operation must be > completely canceled before sane_cancel returns. If it's call asynchronously > (case I), the request must be postponed by setting a flag for example. The > request will be carried out when we return to the reader thread. Why not just kill the reader process in sane_cancel? Do you think the way this is done in the existing backends (e.g. mustek) is wrong? Bye, Henning
