[sane-devel] USB device locking in the snapscan backend

[Julien BLACHE]

Oliver Schwartz <Oliver.Schwartz at gmx.de> wrote:

Hi,

>> I /think/ this was done in an attempt to avoid backtracking on SCSI
>> scanners, at the time.
>
> Yes, probably. Backtracking may also happen with USB, though.

SCSI was mainstream for sanners back in those days, I guess ;) But
backtracking is a generic problem, right.

>> If I understand that correctly, the locking is there to avoid a
>> possible race between two commands from 2 processes that could lead to
>> the wrong command to be added to the queue. Correct ?
>
> That's also my understanding.

Great, now we know what we're talking about :)

>> The reader task thing is a bit suboptimal anyway; I've got a bug
>> report about that fact. In a nutshell: due to both tasks having the
>> same priority wrt scheduling, both have the same timeslice allocated,
>> and depending on how the main task is designed, it can end up using
>> its timeslice doing nothing instead of giving it up and having the
>> reader task benefit from that. You can actually double the throughput
>> by renicing the tasks.
>
> Interesting - sounds like a design flaw in the main task to me.

Well, no. The only way to avoid this problem is to renice the main
task to a lower priority (since you can't renice the reader task to a
higher priority without being root) which means you're going to renice
the GUI to a lower priority - because that's actually the main task.

JB.

-- 
Julien BLACHE                                   <http://www.jblache.org> 
<jb at jblache.org>                                  GPG KeyID 0xF5D65169