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

[abel deuring]

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...

Abel

(*) 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.