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
