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

[Henning Meier-Geinitz]

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