[sane-devel] xscanimage handling for non-blocking fd

Henning Meier-Geinitz henning@meier-geinitz.de
Mon, 23 Aug 2004 18:54:35 +0200


Hi,

On Sun, Aug 22, 2004 at 06:14:05PM -0400, James A. Littlefield wrote:
> I have run across another issue during DS3000 backend testing.    When 
> using xscanimage if I let scans run to completion everything is fine.    
> If I use the "Cancel" button in the scan progress window the button 
> stays depressed,  the scanner correctly aborts the scan and returns to 
> home,  but the scan progress window remains open (with cancel button 
> depressed), and the main xscanimage window has the "Scan" button 
> disabled.     This behavior occurs if I have the backend compiled to 
> support both sane_get_select_fd() and also sane_set_io_mode() with 
> non-blocking I/O support.       If I recompile the chinon backend to 
> support only blocking io then the cancel feature works correctly.
> 
> After some poking around w/ gdb I have developed a theory that when the 
> scan is cancelled and the pipe between the reader_process and xscanimage 
> is closed this is causing an exception condition on the fd returned by 
> sane_get_select_fd().    Somehow this causes the event handling in 
> xscanimage to hang....
> 
> Has anyone seem similar behavior w/ other backends that support both the 
> select fd and non-blocking io?    Any suggestions/tips appreciated.

That's an old problem and I'm not sure if it has been fixed in
xscanimage. Does it also happen with xsane? It shouldn't.

Keep in mind that according to the SANE standard the backend must
close the pipe file descriptor to tell the frontend that EOF will
happen with the next sane_read. Closing the "other end of the pipe" is
not enought.

You may be right with the hang. I remeber that with xsane there was
once a similar problem because the gdk code wasn't able to detect the
"file descriptor closed" condition unlike select. But I don't remeber
how Oliver fixed that.

Bye,
  Henning