[sane-devel] Signal-Handling-Question ( OS/2)
Henning Meier-Geinitz
henning at meier-geinitz.de
Sun Nov 23 12:35:37 GMT 2003
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
More information about the sane-devel
mailing list