Hi, On Mon, Nov 24, 2003 at 01:00:06AM +0100, Franz Bakan wrote: > On Sun, 23 Nov 2003 13:35:37 +0100, Henning Meier-Geinitz wrote: > > >> - How to tell scanimage that the scanner allready has stopped? > > > >Well, the backend should know about that. E.g. the mustek backend > >blocks signals while doing a SCSI transfer. > > So the epson backend should be modified and not the > OS/2-SCSI-I/O functions?
At least currently the backends themselves make sure that SCSI requests are not interrupted. Well, they should make sure. grep SIGTERM backend/*.c Maybe it would be better if sanei_scsi.c takes care for that but I haven't looked at the implications yet. > > >After the transfer is finished, the reader_process terminates > >and sanei_scsi_flush_all is called. > > but anei_scsi_flush_all() looks like a dummy-function for me. Huh? At least for Linux, it calls flush_all_extended (fd) which stops all running SCSI requests. > > >> - How do I correctly delay SIG_INT with unix-like functions? > > > >For how to block sigterm, see the mustek backend. > > So Ctrl+C sends SIG_TERM and not SIG_INT ? No, it sends SIGINT. The scanimage sigint handler catches that interrupt and calls sane_cancel() of the backend. In the mustek backend (and other backends) sane_cancel kills the reader_process with SIGTERM. So the reader process blocks SIGTERM while sending a SCSI request. > >TI think threading just does not work with those signals as expected. > >I think Gerhard has already written an email about that topic on > >sane-devel some time ago. > > I remember, but epson-scsi-backend does not use threading. It may be a completely different problem in epson.c. I haven't looked at the code, maybe it doesn't block SIGTERM or does not sue a reader process at all. Anyway, the backend should make sure that sane_cancel works at any time. Bye, Henning
