[sane-devel] [RFC] Locking devices via sanei_access lib...

[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?

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 ;)