[sane-devel] Signal-Handling-Question ( OS/2)
Mon, 24 Nov 2003 15:16:21 +0100
Henning Meier-Geinitz wrote:
>>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.
Only the Linux part of sanei_scsi.c has more or less(*) real queueing
capabilities. For all other implemetations, the SCSI system of the OS is
"executing" at most one command, so there is no need to stop
not-yet-finished commands in sanei_scsi_req_flush_all(_extended). But
sanei_scsi_req_flush_all might be the right place to fix issues with
signal handling, because this function is called from the signal
handlers of many backends. I am though not sure that I understood the
signal handling problem described by Franz for OS/2 -- so it's possible
that this suggestion is nonsense...
(*) many SCSI disks have real queueing capabilities (called tagged
queueing): A host can issue more than one READ or WRITE command, and the
disk can return commands in any order. In contrast, I haven't heard
about a SCSI scanner which supports this type of queueing. But the
"queueing implementation" in sanei_scsi.c for Linux can nevertheless be
very useful. The SCSI system of the kernel can queue two or more SCSI
commands and can thus reduce the latency between two commands. For
certain scanners, this reduced latency can avoid some or all scanhead stops.