On Thursday 10 January 2008, m. allan noah wrote: > > but only if they coordinate who's documents are on the scanner at that > moment.
I suppose an argument can be made for both approaches to locking, but users sharing a network scanner must coordinate their usage by some means. Somebody has to put their documents on the scanner then start the scan. The SP15C doesn't have a "Start Scan" button, so the user must return to their desk to start the scan from whatever program they're using for scanning. During the scan (set_window, trigger_scan, sane_read) the scanner must be locked (reserved) of course. When other users see that the scanner has documents on it, they'll just have to wait their turn (no need for a queue manager). > some backends now implement a locking feature to prevent > exactly this kind of access. it is made possible by the fact that > sp15c.c closes the file handle at the end of attach, and does not > re-open it til sane_start. this comment precedes the call to close: /* > Why? */. Concurrent access is why, i suppose :) With backends that > know how to read scanner sensors and buttons, this means a lot of > opening and closing... Well, I prefer the sp15c's concurrency. It means a user can use xsane for color/image adjustment, and gscans2pdf for its integration with tesseract, without having to open/close each program in turn -- they can keep their custom gamma tables and preview window sizes in xsane but temporarily switch to another frontend without having to exit xsane. --- Jeremy
