[sane-devel] Signal-Handling-Question ( OS/2)
Sun, 23 Nov 2003 13:35:37 +0100
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
> In a second approach I've tried the following:
> /* Prevent the calling process from being killed */
> sigprocmask(SIG_BLOCK, &all, &oldset);
> /* 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.