Hi, On Fri, Nov 21, 2003 at 01:43:19AM +0100, Franz Bakan wrote: > But this 'solution' is not perfect. When I now 'Ctrl+C' the scanner stops, > the error-LED on the scanner (EPSON GT-9500) lights up and > scanimage tells: > > scanimage.exe: received signal 2 > scanimage.exe: trying to stop scanner > > and _wait's_ until I SIGKILL the process (second Ctrl+C doesn't work).
On the first ctrl-c scanimage calls sane_cancel(). This is done immediately while a different sane_* api function may be running (e.g. sane_read(). While this is allowed by the SANE standard, nome backends may not be able to cope with that. If you press ctrl-c a second time, scanimage will just exit without waiting for sane_cancel and the cancelled operation to return. > - 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. After the transfer is finished, the reader_process terminates and sanei_scsi_flush_all is called. > In a second approach I've tried the following: > > /* Prevent the calling process from being killed */ > sigfillset(&all); > sigprocmask(SIG_BLOCK, &all, &oldset); > > DosDevIOCtl() > > /* Now it is ok to be killed */ > sigprocmask(SIG_SETMASK, &oldset, NULL); > > But this way the machine still crashes hard when entering Ctrl+C > (Perhaps I made a mistake with the syntax?) > > - How do I correctly delay SIG_INT with unix-like functions? For how to block sigterm, see the mustek backend. 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. Bye, Henning
