Am Mon, 2005-02-07 um 20.10 schrieb Gerhard Jaeger: > On Monday 07 February 2005 16:50, Oliver Rauch wrote: > > Am Mon, 2005-02-07 um 14.10 schrieb Gerhard Jaeger: > > > Hi, > > > > > > On Monday 07 February 2005 12:41, Johannes Meixner wrote: > > > > Hello, > > > > > > > > On Feb 7 12:11 Gerhard Jaeger wrote (shortened): > > > > > The idea is to provide a simple locking mechanism for the backends, > > > > > to have exclusive access to one scanner during an operation: > > > > > > > > ... > > > > > > > > > What do you guys think of this lib - is it useful? > > > > > > > > I even think exclusive access should be used by default > > > > because I think normally it doesn't make sense when there > > > > is more than one process which talks to the same scanner > > > > (i.e. "the same scanner" but not "the same backend" because > > > > one backend can drive several scanners). > > > > > > I agree! Each device a backend talks to needs some exclusive > > > locking! > > > > We already had a discussion about this some time ago (2-3 years). > > My opinion is a bit different. > > Really ;) > > > On my work we have one scanner and about 30 people who have access > > to the scanner. And I know that some people keep open the > > scanning frontend all the time. With exclusive locking the device > > would almost be unusable. > > I totally agree. The button-daemon also keeps the backend always open. > > > > > The umax (scsi) backend locks the scanner when sane_start is called > > and releases the scanner when sane_cancel is called. This way there > > is no problem to keep the frontend opened all the time. > > Oh, I didn't know this - how is this done in the umax backend?
The umax scsi scanners have a command RESERVE_UNIT and a command RELEASE_UNIT that is used for device internal locking. Oliver > > In my test-implementation also only the "real" device access > is locked exclusive. This real access covers - detection (during sane_init), > button status check (sane_control_option) and calibration/scanning > (sane_open/sane_cancel). > > > > > I think it makes sense that opening the scanning frontend does not > > lock the device. But in this case we need at least a button locking. > > Absolutely - and for this locking, I'd like to have one common lib, like > the sanei_thread lib. > > Gerhard > > > > > Oliver > > > > > > Once it happened while I did a nice (you may say stupid) stress test > > > > > > > > for i in $( seq 100 ) > > > > do sane-find-scanner & scanimage -L & > > > > done > > > > > > > > that one of my USB scanners made funny noise: It seems it tried > > > > to move its scanning unit beyond its physical limits. > > > > I have no idea how this could have happened but I guess the scanner > > > > was simply totally confused by the multiple concurrent accesses. > > > > > > It should not happen, but even such stupid tests show, that the locking > > > needs to be done in another way, as it's currently done, if it's done. > > > Rather the same "confusion" will happen when you have something > > > like Rene Rebes' button daemon which does nothing else than checking the > > > button status of a scanner - depending on the scanner, the backend needs > > > to check some or at least one register and when another frontend > > > currently is scanning - the scanner will not work properly afterwards > > > (highly depends on that device) > > > > > > > By the way: > > > > The reason for the above stress-test was that this way I could > > > > stop the kernel (no single error message in the logs - just a > > > > sudden stop) - meanwhile I do no longer use the crap SCSI > > > > host adapter ;-) > > > > > > This test should become another stress-test for a new backend ;)
