>> Not really, but I'm not sure it's a good idea to block all
>> signals. You may want to play around with this part. Indeed,
>> for testing purposes you could not block anything and see whether
>> that helps.
Oliver> I will try that, but it is important to block all signals
Oliver> between scsi-command and scsi-answer, otherwise we may block
Oliver> the scsi-bus!
Well, the reason the signals are blocked is to avoid a race condition.
Without blocking the signals, it could happen that:
(1) sanei_scsi.c:issue() gets called
(2) req->running gets set
(3) user hits ctrl-C (or something else that causes a signal)
(4) sane_cancel() gets invoked
(5) sanei_scsi_req_flush_all() gets called by sane_cancel()
(6) sanei_scsi_req_flush_all() sees req->running is set and
now attempts to read() the reply bytes, which of course
will never happen (because issue() never got to write()
the request)
Because of this, all signals that could result in sane_cancel() being
called must be blocked temporarily.
Oliver> Is it possible that it has to do something with
Oliver> command-queing and the cammand-queue is already full?
I suppose it could be. Does the UMAX backend attempt to send any scsi
commands during a sane_cancel() call? I thought not.
--david
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com