[sane-devel] Signal-Handling-Question ( OS/2)

Henning Meier-Geinitz henning@meier-geinitz.de
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 */
>  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.